Re: glib memory checking

[Tim Janik <timj gtk org>]

On Sat, 15 Jul 2000, Michael Meeks wrote:

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

yes, investigated it a bit about a year ago, i don't know where it went
since ;)
a quick grep in /usr/share/doc/dmalloc (i've got it installed as a debian
package) reveals:
copyright:The author may be contacted via http://www.dmalloc.com/

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

we'll be there soon enough with the vtable approach ;)

> 
>         Regards,
> 
>                 Michael.
> 

---
ciaoTJ