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

[Behdad Esfahbod <behdad cs toronto edu>]

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
> > anyway.
>
> 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:

"""
gc-friendly

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

from:

  http://developer.gnome.org/doc/API/2.0/glib/glib-running.html#G_DEBUG


> 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
:).


> > 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.


> >> 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. :)

> 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.
>
> ---
> ciaoTJ

--behdad
http://behdad.org/

"Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
	-- Dan Bern, "New American Language"