alexk at demon.net
Tue Feb 13 15:58:06 UTC 2001
Fabien Tassin <fta at sofaraway.org> writes:
> According to Alex Kiernan:
> > With apologies for the length... looks like theres a few interesting
> > ones shown up overnight (trimmed to just those):
> > **** Purify instrumented /news/bin/innd (pid 25507, forked from pid 25498) ****
> > ABR: Array bounds read:
> > * This is occurring while in:
> > strlen [rtlib.o]
> > x_strdup [xmalloc.c:116]
> > ARTcontrol [art.c:1291]
> > ARTpost [art.c:2677]
> > NCpostit [nc.c:194]
> > NCproc [nc.c:972]
> > * Reading 913 bytes from 0x779428 in the heap (1 byte at 0x7797b8 illegal).
> > * Address 0x779428 is 3184 bytes into a malloc'd block at 0x7787b8 of 4096 bytes.
> > Purify Heap Analysis (combining suppressed and unsuppressed blocks)
> > Blocks Bytes
> > Leaked 654 1061189
> > Potentially Leaked 61 121919
> > In-Use 116257 11233297
> > ----------------------------------------
> > Total Allocated 116972 12416405
> Are these stats taken on the fly or is a complete session (start/run/stop)
> needed ?
> I've tested the malloc checker built in glibc > 2.1 for a complete 'short'
> run, it reports far more than this (hundreds of unfreed locations).
> Unfortunatly, it (mcheck) is only able to report the name of the direct caller
> which is often the x_malloc() wrapper. I usually use dmalloc to detect buffer
> overflows/fence-posts but it is not easily usable in INN due to name
> conflicts. I'll see if I can do something for this in a near future.
On the fly, but purify isn't just counting freed/allocated, its also
tracking live pointers to data; in threaded programs I've seen it get
confused (typically when you're transferring "ownership" of memory
between threads), I don't think I've ever seen it report MLKs which
weren't for real in single threaded apps (which isn't to say this
couldn't be the first time!)
Alex Kiernan, Principal Engineer, Development, Thus PLC
More information about the inn-workers