Purify errors

[Alex Kiernan]

Russ Allbery <rra at stanford.edu> writes:

> Fabien Tassin <fta at sofaraway.org> writes:
> 
> > 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).
> 
> I would trust Purify considerably more than glibc's checker.  It's a shame
> that Purify is commercial because it's really incredible software.  (We
> have a site license here too, and I need to get set up so that I can start
> running it as well.)
> 
> Also, were you compiling with Perl filtering, and if so, is the Perl that
> you're using built with PURIFY defined?  If not, Perl will appear to leak
> memory all over the place due to its internal allocation structure
> creating false positives.
> 

Good point - I've private versions of everything, but haven't built
them all with PURIFY defined (actually checking it looks like it only
really affects perl's internal malloc, which I explicitly told it not
to use - for reasons I can't now remember...); I need to rebuild
everything 64 bit anyway as expire fails because it runs out of
address space :-(

-- 
Alex Kiernan, Principal Engineer, Development, Thus PLC