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

[Tim Janik <timj imendio com>]

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

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

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

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
G_SLICE=always-malloc

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

> --behdad
> http://behdad.org/

---
ciaoTJ