Purify errors

[Alex Kiernan]

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