| 1 | Purify (tm) and Quantify (tm) are commercial software quality
|
|---|
| 2 | assurance tools available from IBM <http://www.ibm.com/software/rational/>.
|
|---|
| 3 | Purify is essentially a memory access
|
|---|
| 4 | verifier and leak detector; Quantify is a C level profiler. The rest
|
|---|
| 5 | of this file assumes you generally know how to use Purify and
|
|---|
| 6 | Quantify, and that you have installed valid licenses for these
|
|---|
| 7 | products. If you haven't installed such licenses, you can ignore the
|
|---|
| 8 | following since it won't help you a bit!
|
|---|
| 9 |
|
|---|
| 10 | You can easily build a Purify or Quantify instrumented version of the
|
|---|
| 11 | Python interpreter by passing the PURIFY variable to the make command
|
|---|
| 12 | at the top of the Python tree:
|
|---|
| 13 |
|
|---|
| 14 | make PURIFY=purify
|
|---|
| 15 |
|
|---|
| 16 | This assumes that the `purify' program is on your $PATH. Note that
|
|---|
| 17 | you cannot both Purify and Quantify the Python interpreter (or any
|
|---|
| 18 | program for that matter) at the same time. If you want to build a
|
|---|
| 19 | Quantify'd interpreter, do this:
|
|---|
| 20 |
|
|---|
| 21 | make PURIFY=quantify
|
|---|
| 22 |
|
|---|
| 23 | Starting with Python 2.3, pymalloc is enabled by default. This
|
|---|
| 24 | will cause many supurious warnings. Modify Objects/obmalloc.c
|
|---|
| 25 | and enable Py_USING_MEMORY_DEBUGGER by uncommenting it.
|
|---|
| 26 | README.valgrind has more details about why this is necessary.
|
|---|
| 27 | See below about setting up suppressions. Some tests may not
|
|---|
| 28 | run well with Purify due to heavy memory or CPU usage. These
|
|---|
| 29 | tests may include: test_largefile, test_import, and test_long.
|
|---|
| 30 |
|
|---|
| 31 | Please report any findings (problems or no warnings) to python-dev@python.org.
|
|---|
| 32 | It may be useful to submit a bug report for any problems.
|
|---|
| 33 |
|
|---|
| 34 | When running the regression test (make test), I have found it useful
|
|---|
| 35 | to set my PURIFYOPTIONS environment variable using the following
|
|---|
| 36 | (bash) shell function. Check out the Purify documentation for
|
|---|
| 37 | details:
|
|---|
| 38 |
|
|---|
| 39 | p() {
|
|---|
| 40 | chainlen='-chain-length=12'
|
|---|
| 41 | 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"'
|
|---|
| 42 | followchild='-follow-child-processes=yes'
|
|---|
| 43 | threads='-max-threads=50'
|
|---|
| 44 | export PURIFYOPTIONS="$chainlen $ignoresigs $followchild $threads"
|
|---|
| 45 | echo $PURIFYOPTIONS
|
|---|
| 46 | }
|
|---|
| 47 |
|
|---|
| 48 | Note that you may want to crank -chain-length up even further. A
|
|---|
| 49 | value of 20 should get you the entire stack up into the Python C code
|
|---|
| 50 | in all situations.
|
|---|
| 51 |
|
|---|
| 52 | With the regression test on a fatly configured interpreter
|
|---|
| 53 | (i.e. including as many modules as possible in your Modules/Setup
|
|---|
| 54 | file), you'll probably get a gabillion UMR errors, and a few MLK
|
|---|
| 55 | errors. I think most of these can be safely suppressed by putting the
|
|---|
| 56 | following in your .purify file:
|
|---|
| 57 |
|
|---|
| 58 | suppress umr ...; "socketmodule.c"
|
|---|
| 59 | suppress umr ...; time_strftime
|
|---|
| 60 | suppress umr ...; "dbmmodule.c"
|
|---|
| 61 | suppress umr ...; "gdbmmodule.c"
|
|---|
| 62 | suppress umr ...; "grpmodule.c"
|
|---|
| 63 | suppress umr ...; "nismodule.c"
|
|---|
| 64 | suppress umr ...; "pwdmodule.c"
|
|---|
| 65 |
|
|---|
| 66 | Note: this list is very old and may not be accurate any longer.
|
|---|
| 67 | It's possible some of these no longer need to be suppressed.
|
|---|
| 68 | You will also need to suppress warnings (at least umr)
|
|---|
| 69 | from Py_ADDRESS_IN_RANGE.
|
|---|
| 70 |
|
|---|
| 71 | This will still leave you with just a few UMR, mostly in the readline
|
|---|
| 72 | library, which you can safely ignore. A lot of work has gone into
|
|---|
| 73 | Python 1.5 to plug as many leaks as possible.
|
|---|
| 74 |
|
|---|
| 75 | Using Purify or Quantify in this way will give you coarse grained
|
|---|
| 76 | reports on the whole Python interpreter. You can actually get more
|
|---|
| 77 | fine grained control over both by linking with the optional `pure'
|
|---|
| 78 | module, which exports (most of) the Purify and Quantify C API's into
|
|---|
| 79 | Python. To link in this module (it must be statically linked), edit
|
|---|
| 80 | your Modules/Setup file for your site, and rebuild the interpreter.
|
|---|
| 81 | You might want to check out the comments in the Modules/puremodule.c
|
|---|
| 82 | file for some idiosyncrasies.
|
|---|
| 83 |
|
|---|
| 84 | Using this module, you can actually profile or leak test a small
|
|---|
| 85 | section of code, instead of the whole interpreter. Using this in
|
|---|
| 86 | conjuction with pdb.py, dbx, or the profiler.py module really gives
|
|---|
| 87 | you quite a bit of introspective power.
|
|---|
| 88 |
|
|---|
| 89 | Naturally there are a couple of caveats. This has only been tested
|
|---|
| 90 | with Purify 4.0.1 and Quantify 2.1-beta on Solaris 2.5. Purify 4.0.1
|
|---|
| 91 | does not work with Solaris 2.6, but Purify 4.1 which reportedly will,
|
|---|
| 92 | is currently in beta test. There are funky problems when Purify'ing a
|
|---|
| 93 | Python interpreter build with threads. I've had a lot of problems
|
|---|
| 94 | getting this to work, so I generally don't build with threads when I'm
|
|---|
| 95 | Purify'ing. If you get this to work, let us know!
|
|---|
| 96 |
|
|---|
| 97 | -Barry Warsaw <bwarsaw@cnri.reston.va.us>
|
|---|