Re: glib memory checking

[Michael Meeks <michael helixcode com>]

Hi,

On Sat, 15 Jul 2000, Tim Janik wrote:
> as a userbase for the profiling and debugging code is provably in
existance

        Indeed =)

> and for all (and still enables debugging/profiling variants for those   
> that can't use dmalloc or memprof etc. tools for whatever reasons).

        Well; I had a look at fitting memory stamping for free'd memory
into memprof; the problem is that the size data for the block is stored in
the central process at the other end of a unidirectional buffered pipe
IIRC. So, the option of making that bidirectional and blocking on read  
each time we do a free was not attractive. Consequently memprof can't do
what g_free can do. Furthermore I know nothing about dmalloc; is it free
software ? if so is there a URL ?
  
        The suggestion of using 0xdeadbeef significantly complicates the
code since we can't just do a nice memset (), however simply changing a
0x0 to a 0x2e in the code is an extremely minor and useful change.
  
> 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. 
 
        Yes indeed, I have been running over Gnome code and fixing
seg-faults left right and centre, however plugging 0x2e in I have managed
to find a lot of bugs that use memory immediately after freeing it and
that can cope with 0 / NULL values in that memory.

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

        Sure; this is a fairly nice solution, I imagine the extra overhead
is insignificant in comparison to the dynamic allocation algorithem's
work.

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

        Excellent, but for now can we switch to 0x2e =)

        Regards,

                Michael.

-- 
 mmeeks@gnu.org  <><, Pseudo Engineer, itinerant idiot