Re: [Numpy-discussion] Strange and hard to reproduce crash

[Albert S. <fu...@gm...>]

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:

http://svn.python.org/view/python/trunk/Misc/valgrind-python.supp?rev=47113&
view=auto

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 \
        python foo.py

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

http://www.valgrind.org/downloads/current.html#current

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

Cheers,

Albert

> -----Original Message-----
> From: num...@li... [mailto:numpy-
> dis...@li...] 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]: '0.5.0.2180'
> 
> 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>