Re: glib memory checking

[Tim Janik <timj gtk org>]

On Thu, 13 Jul 2000, Michael Meeks wrote:

> 
> Hi there,
> 
> 	I was just using the ( excellent ) memory checking code in
> glib, and I notice that g_free does a memset (memory, 0, size).
> Some time ago I read a tome entitled 'Writing Solid Code' from
> Microsoft Press, gags etc, and they suggest setting memory to 0x2e
> IIRC, perhaps it halts if you execute it. Either way it seems to
> me rather daft to set the memory to what ammounts to a load of NULL
> pointers on most architectures, since much buggy code will work
> fine eg. a double g_free with this setup.
> 
> 	Any chance of making it some strange constant instead ?

ok, first, there've been many threads on glib memory allocation
over the (post-1.2) past, covering many different aspects.

imediately accessible in my faulty memory are the following:
- be able to recover from failing allocations (i.e. NULL returns
  where we simply abort currently)
- refining the current profiling/debugging code
- provide more intelligent statistics since glib does a lot of caching
- cutting down the memory footprint since glib does lots of "caching",
  i.e. of freed structures to speed up new allocations

the rough consensus (it apeared after some lengthy discussions which
some would call flamewars) was that we only provide:

g_try_malloc(), g_try_new() and g_try_realloc() as non-aborting variants
of what we currently have, and get rid of the profiling, debugging code
and dmalloc support entirely.

however, one of the proposals was to enable setting of a malloc fuctions
VTable to fully virtualize glib's allocator functions.

as a userbase for the profiling and debugging code is provably in existance
(meanwhile we even received bug reports + fixes for some of the profiling
code), we'll probably end up with that vtable approach, since that's the
only way to cover up for the different needs of various developers once
and for all (and still enables debugging/profiling variants for those
that can't use dmalloc or memprof etc. tools for whatever reasons).

one thing to note here is that for ages we've been recommending that stuff
allocated through g_* may only be freed with the corresponding g_*
variants, and the current debugging code will pretty quickly tell you if
you g_free(malloc()), so this is definitely viable.

that way you'll also be able to plug your 0x2e or 0xdeadbeef cleaners ;)

similar to the current G_DISABLE_ASSERT, there will probably also be a
G_ENABLE_MEMSAVE define, settable through a configure.in option, that
can disable the caching behaviour for those portions that people dare
patching.

> 
> 	Regards,
> 
> 		Michael.
> 

---
ciaoTJ