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
