mirror of
https://github.com/python/cpython
synced 2024-11-02 15:20:44 +00:00
81 lines
3.6 KiB
Text
81 lines
3.6 KiB
Text
Purify (tm) and Quantify (tm) are commercial software quality
|
|
assurance tools available from Rational Software Corporation
|
|
<http://www.rational.com/>. Purify is essentially a memory access
|
|
verifier and leak detector; Quantify is a C level profiler. The rest
|
|
of this file assumes you generally know how to use Purify and
|
|
Quantify, and that you have installed valid licenses for these
|
|
products. If you haven't installed such licenses, you can ignore the
|
|
following since it won't help you a bit!
|
|
|
|
You can easily build a Purify or Quantify instrumented version of the
|
|
Python interpreter by passing the PURIFY variable to the make command
|
|
at the top of the Python tree:
|
|
|
|
make PURIFY=purify
|
|
|
|
This assumes that the `purify' program is on your $PATH. Note that
|
|
you cannot both Purify and Quantify the Python interpreter (or any
|
|
program for that matter) at the same time. If you want to build a
|
|
Quantify'd interpreter, do this:
|
|
|
|
make PURIFY=quantify
|
|
|
|
When running the regression test (make test), I have found it useful
|
|
to set my PURIFYOPTIONS environment variable using the following
|
|
(bash) shell function. Check out the Purify documentation for
|
|
details:
|
|
|
|
p() {
|
|
chainlen='-chain-length=12'
|
|
ignoresigs='-ignore-signals="SIGHUP,SIGINT,SIGQUIT,SIGILL,SIGTRAP,SIGAVRT,SIGEMT,SIGFPE,SIGKILL,SIGBUS,SIGSEGV,SIGPIPE,SIGTERM,SIGUSR1,SIGUSR2,SIGPOLL,SIGXCPU,SIGXFSZ,SIGFREEZE,SIGTHAW,SIGRTMIN,SIGRTMAX"'
|
|
followchild='-follow-child-processes=yes'
|
|
threads='-max-threads=50'
|
|
export PURIFYOPTIONS="$chainlen $ignoresigs $followchild $threads"
|
|
echo $PURIFYOPTIONS
|
|
}
|
|
|
|
Note that you may want to crank -chain-length up even further. A
|
|
value of 20 should get you the entire stack up into the Python C code
|
|
in all situations.
|
|
|
|
With the regression test on a fatly configured interpreter
|
|
(i.e. including as many modules as possible in your Modules/Setup
|
|
file), you'll probably get a gabillion UMR errors, and a few MLK
|
|
errors. I think most of these can be safely suppressed by putting the
|
|
following in your .purify file:
|
|
|
|
suppress umr ...; "socketmodule.c"
|
|
suppress umr ...; time_strftime
|
|
suppress umr ...; "dbmmodule.c"
|
|
suppress umr ...; "gdbmmodule.c"
|
|
suppress umr ...; "grpmodule.c"
|
|
suppress umr ...; "nismodule.c"
|
|
suppress umr ...; "pwdmodule.c"
|
|
|
|
This will still leave you with just a few UMR, mostly in the readline
|
|
library, which you can safely ignore. A lot of work has gone into
|
|
Python 1.5 to plug as many leaks as possible.
|
|
|
|
Using Purify or Quantify in this way will give you coarse grained
|
|
reports on the whole Python interpreter. You can actually get more
|
|
fine grained control over both by linking with the optional `pure'
|
|
module, which exports (most of) the Purify and Quantify C API's into
|
|
Python. To link in this module (it must be statically linked), edit
|
|
your Modules/Setup file for your site, and rebuild the interpreter.
|
|
You might want to check out the comments in the Modules/puremodule.c
|
|
file for some idiosyncrasies.
|
|
|
|
Using this module, you can actually profile or leak test a small
|
|
section of code, instead of the whole interpreter. Using this in
|
|
conjuction with pdb.py, dbx, or the profiler.py module really gives
|
|
you quite a bit of introspective power.
|
|
|
|
Naturally there are a couple of caveats. This has only been tested
|
|
with Purify 4.0.1 and Quantify 2.1-beta on Solaris 2.5. Purify 4.0.1
|
|
does not work with Solaris 2.6, but Purify 4.1 which reportedly will,
|
|
is currently in beta test. There are funky problems when Purify'ing a
|
|
Python interpreter build with threads. I've had a lot of problems
|
|
getting this to work, so I generally don't build with threads when I'm
|
|
Purify'ing. If you get this to work, let us know!
|
|
|
|
-Barry Warsaw <bwarsaw@cnri.reston.va.us>
|