Strange and hard to reproduce crash

Albert Strasheim fullung at
Mon Oct 23 17:07:02 CDT 2006

Hey Fernando

Maybe you can give the code a spin under Valgrind. It's going to be slow,
but if the crash is being caused by memory corruption that happens all the
time as the process is running, maybe Valgrind will show it.

You need some Valgrind suppressions for Python. It seems the 2.3 source tree
didn't contain these yet, so try the one from trunk:

I then run Valgrind as follows:

valgrind \
        --tool=memcheck \
        --leak-check=yes \
        --error-limit=no \
        --suppressions=valgrind-python.supp \
        --num-callers=20 \
        --freelist-vol=536870912 \
        -v \

I recommend using the latest Valgrind (3.2.1) from here:

A build from source should be as simple as ./configure && make.



> -----Original Message-----
> From: numpy-discussion-bounces at [mailto:numpy-
> discussion-bounces at] On Behalf Of Fernando Perez
> Sent: Monday, October 23, 2006 11:40 PM
> To: Discussion of Numerical Python
> Subject: [Numpy-discussion] Strange and hard to reproduce crash
> Hi all,
> two colleagues have been seeing occasional crashes from very
> long-running code which uses numpy.  We've now gotten a backtrace from
> one such crash, unfortunately it uses a build from a few days ago:
> In [3]: numpy.__version__
> Out[3]: '1.0b5.dev3097'
> In [4]: scipy.__version__
> Out[4]: ''
> Because it takes so long to get the code to crash (several days of
> 100%CPU usage), I can't make a new one right now, but I'll be happy to
> restart the same run with a current SVN build if necessary, and post
> the results in a few days.

> <snip>

Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo

More information about the Numpy-discussion mailing list