Re: changing --enable-gc-friendly=yes semantics

On Wed, 25 Jan 2006, Behdad Esfahbod wrote:

On Wed, 25 Jan 2006, Tim Janik wrote:

On Wed, 25 Jan 2006, Behdad Esfahbod wrote:

On Wed, 25 Jan 2006, Tim Janik wrote:

as suggested earlier this week to matthias, i've now introduced
G_DEBUG=gc-friendly in CVS. this is compiled unconditionally into
GLib, so with the next development release, it'll be usable for
all glib applications to 0-out released memory.

Humm, is it true that gc-friendly makes valgrind not err about
uninitialized access memory problems?  Since you are zeroing
malloc()ed memory, right?  And g_slice_ doesn't return memory

no, and no.

gc-friendly does *not* turn g_malloc() into g_malloc0(), it just
zeros the memory passed in to free().

Then maybe you need to update the docs that you linked:


Newly allocated memory that isn't directly initialized, as well
as memory being freed will be reset to 0.

yes and no. i've had the same thought when copying over the description
from macros.txt. but it doesn't address g_malloc() particularly which
doesn't do this, for other code portion, the 0ing is actually true, i.e.
GArray (and in the future there can be others).


and g_slice_alloc()/g_slice_new() does of course return memory (newly
allocated), since it's an allocator API.

I mean it doesn't return it to glibc on every g_slice_free.  So
it reuses allocated memory, which hides uninitialized access
problem again.  Unless I'm misunderstanding g_slice completely

you're right, GSlice doesn't immediately return memory to glibc (on
average it does after 15 seconds though), unless you tell it to, via

Guess we should add a compile-time --with-valgrind option and add
some valgrind hooks to glib memory functions.

what for? i can't see any need for that. especially since valgrind
correctly hooks the systems malloc/free calls anyway.

Right, but glib doesn't do malloc/free on every
g_slice_new/g_slice_free, unless G_SLICE=always-malloc.

yes, that's still not a reason for --with-valgrind, at least i don't see it ;)

this changes the --enable-gc-friendly=yes semantics slightly,
instead of enabling the compilation of gc-friendly code portions,
it now changes the glib default for gboolean glib_mem_gc_friendly;
from FALSE to TRUE.

Any way to turn it off using the env var?  G_DEBUG=no-gc-friendly
pops to my mind...  Same for other settings too maybe?

well, that could be added, but i suppose the use case is very rare,
why would you configure glib with --enable-gc-friendly=yes and then
start apps with G_DEBUG=no-gc-friendly? (not-gc-friendly, gc-unfriendly, ... ;)

To be able to use valgrind for access problems instead of leak
problems, with my assumptions above. :)

well, still i think the normal use case is to compile glib without
--enable-gc-friendly, and just make use of G_DEBUG=gc-friendly in the
few cases where the applications you run actually run inside valgrind.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]