Re: glib memory checking
- From: Pavel Císler <pavel eazel com>
- To: Michael Meeks <mmeeks gnu org>, gtk-devel-list redhat com
- Subject: Re: glib memory checking
- Date: Sat, 15 Jul 2000 14:24:52 -0700
> 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 ?
>
You could check out the leakchecker tool in nautilus. It's not as
sophisticated as memprof, I just needed something that wouldn't get confused
by threading. I copied most of its guts from memprof. Unlike memprof it lives
in the same process as the leakchecked target so it would be easy to hack it
to lay deadbeef into freed memory.
Some other malloc libraries I've seen before had an equivalent of
MALLOC_CHECK_ that had several different levels with increasing number of
tests. As you turned up the level, more checks would run (and mallocs would
slow down a bit more). Besides filling freed memory with 0xdeadbeef, doing a
heap consistency check periodically, etc. the more thorough levels also
implemented things like purgatory lists - freed blocks were kept unused for a
long time and kept getting checked periodically for data written into them.
It sould be cool/fun to add these to g_malloc, etc.
Pavel
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]