From: jbuck@forney.eecs.berkeley.edu (Joe Buck) Subject: Purify (was Re: gcc on linux) Date: 8 Jun 1993 01:03:29 GMT
In article <C89v9y.LMM@boulder.parcplace.com> imp@boulder.parcplace.com (Warner Losh) writes:
>In article <1993Jun7.204515.7634@kf8nh.wariat.org>
>bsa@kf8nh.wariat.org (Brandon S. Allbery) writes:
>>The concept behind purify is fairly simple: [...]
>
>While that would be a reasonable way to implement purify, I think that
>purify uses a series of calls to runtime checking routines, rather
>than signal handlers to implement what it does. I'm not positive, but
>it seems that purify runs too fast to be trapping on every data/bss
>reference.
Purify does not use signal handlers. Rather, it operates on the object
code, modifying it to insert extra code between every read from memory and
write to memory (basically, a procedure call). This results in a speed
penalty of from 2 to 4x. This is far, far faster than traps for every
load or store would be.
This code modification step takes place after compilation and before
linking. The speed penalty would be somewhat higher and the job would be
more complicated on the 386/486 because the Sparc is a RISC machine with a
load-store architecture, while the x86 is a CISC and has many instructions
that access memory.
It seems that it would be possible to modify gcc to insert the read and
write checking calls for every memory access and do the same job: the
advantage of the Purify approach over this approach is that Purify checks
everything (it reports a number of bugs in SunOS 4.x's libc routines, for
example -- e.g. "ctime" writes one byte beyond the end of a malloc'd array).
Purify detects memory leaks not by seeing which blocks are malloc'ed and
never freed, but by using a conservative garbage collector. That way
leaks can be detected as soon as they happen (as soon as the last pointer
to a malloc'ed block is lost) rather than waiting until the end.
A conservative garbage collector assumes any integer on the stack or in a
heap object may actually be a pointer; it errs on the side of safety. It
doesn't actually do garbage collection: think of it as "garbage detection."
You can find a technical paper explaining how Purify does what it does in
the Usenix conference proceedings -- winter '91, I think.