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

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().
and g_slice_alloc()/g_slice_new() does of course return memory (newly
allocated), since it's an allocator API.

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.

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, ... ;)

leaving --enable-gc-friendly in place at all was more of a compatibility
decision than anything else. by continuing to support it in glib and
defaulting to G_DEBUG=gc-friendly that way, existing automated testing
frameworks will continue to function as expected.


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