Re: ustring memory leak

[Fabian Jacquet <fabian jacquet gmail com>]

Mh,

Very interesting, thank you.

I already try with "G_SLICE=always-malloc" environment variable and here is the result.
Leak of 835584/1000 or 835
Leak of 811008/1000 or 811
Leak of 724992/1000 or 724
Leak of 720896/1000 or 720
Leak of 720896/1000 or 720
Leak of 724992/1000 or 724
Leak of 724992/1000 or 724

So, we still have a memory leak but less.
Maybe is it interesting for future investigations.

On Fri, Apr 2, 2010 at 12:19, Chris Vine <chris cvine freeserve co uk> wrote:

On Fri, 2 Apr 2010 10:00:01 +0200

Fabian Jacquet <fabian jacquet gmail com> wrote:

> I have no  problem with the constructor.
> I need to use a compare to have the memory leak.
>
> I think your are right about memory slices. Do you think it's
> possible... 1) to free the slices when I finish my threads (my
> Windows threads) or
> 2) to compile GLib without the feature which uses memory slices for
> thread?

There are a couple of things to do for testing purposes.
http://library.gnome.org/devel/glib/stable/glib-running.html

You can compile glib with the --enable-debug option and then set the
environmental variable G_DEBUG to gc-friendly.  If that stops the
report of a leak then it is a reporting issue, and no memory is in fact
reserved from the operating system.  If recompiled for debug, you can
also call g_slice_debug_tree_statistics() to get glib's idea about
memory usage.  (You can also get a similar effect, without being able to
call g_slice_debug_tree_statistics(), by compiling glib with the
--enable-gc-friendly compilation option.)

You can run your test application with the environmental variable
G_SLICE set to always-malloc, to use g_malloc() instead of slices.  If
that causes the "leak" to disappear then it is memory slices causing the
effect you mention, or at least false reporting if you haven't tried
the gc-friendly test yet. (You don't need to recompile glib for
debugging in order to test this.)

However if the effect disappears by setting G_SLICE to always-malloc
and it isn't a reporting issue, this does not mean there is actually a
leak. If you started losing many megabytes of memory then it is,
and you ought to report a bug; otherwise just be pleased that you have
a very efficient memory allocator.  Allocating memory with the slab
allocator is not a great deal less efficient that constructing objects
on the stack.

You cannot "free" glib's internal memory.  glib does that itself.  I
notice that there is a --disable-mem-pools compilation option for
glib.  I don't know what that does.

Chris