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 <[email protected]>wrote: > On Fri, 2 Apr 2010 10:00:01 +0200 > Fabian Jacquet <[email protected]> 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 >
_______________________________________________ gtkmm-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkmm-list
