[SciPy-dev] segmentation with scipy+icc during test

Stijn De Weirdt stijn.deweirdt@ugent...
Fri Dec 5 14:00:08 CST 2008


hi,

just to be clear, i'm not asking any advice how to build scipy with icc,
i just want to now how to debug the problem and skip some of the tests.

to get back to the link blog: what is described there is a numpy issue
and i dealt with that using the advice the guy got from intel: link mkl
blas and lapack statically. 
numpy builds and works, it's scipy that causes the segfault (although
scipy uses the same build options as numpy. (i'm not saying that the
segfault has nothing to do with using icc/ifort/icpc, just that it's not
this specific problem).

i actually just found out that while running the scipy tests, gcc is
called. i always assumed that scipy takes whatever numpy uses. (it
seemed to work pretty well). maybe the tests don't?

stijn
 

> Hi,
> 
> I think you are in trouble:
> http://matt.eifelle.com/2008/11/03/i-used-the-latest-mkl-with-numpy-and.../
> Unfortunately, I don't have a solution out of the box. It would need
> some distutils hack to solve the issue. Use 10.0.2 instead.
> 
> Matthieu
> 
> 2008/12/5 Stijn De Weirdt <stijn.deweirdt@ugent.be>:
> > hi all,
> >
> > i hope i can bother the dev list with this, as it's not a real user
> > problem imho.
> >
> > i'm trying to compile python+numpy+scipy with intel toolkit (ictce
> > 3.2.0.17, which has icc/ifc 11.0.069 and mkl 10.1.0.015
> >
> >
> > python 2.4.5 compiles and the make tests works fine
> > numpy 1.2.1 compiles and the tests are also fine
> > scipy 0.6.0 compiles, but one of the tests exits with a segmentation
> > fault. (i also tried 0.7.0b1, but it also gives segfualt, but haven't
> > verified if it's the same one)
> >
> > now i'm trying to figure out which test causes the crash and i have some
> > questions related to that:
> > a. how can i skip/reorder tests? (just to check if it's an individual
> > issue or a broader one)
> > b. the segfault itself:
> > python -v -c 'import scipy; scipy.test(level=10,verbosity=100)'
> > ...
> >
> > bench_random (scipy.fftpack.tests.test_basic.test_fft)
> >                 Fast Fourier Transform
> > =================================================
> >      |    real input     |   complex input
> > -------------------------------------------------
> >  size |  scipy  |  numpy  |  scipy  |  numpy
> > -------------------------------------------------
> >  100 |    0.07 |    0.06Segmentation fault
> >
> > looking at the code in scipy/fftpack/tests/test_basic.py, it's the
> > complex part of bench_random that fails.
> >
> > the basic code that triggers it, is (at least that how i read it)
> >
> > x= random([size]).astype(cdouble)+random([size]).astype(cdou\
> > ble)*1j
> > y = direct_dft(x) ## size < 500
> > z=fft(x)
> >
> > with fft loaded from scipy.fftpack (not from numpy)
> > (i'm sure it segfaults during the fft(x) call, because i added some
> > print statements to locate the exact code).
> >
> > when i add some pprint statements to dump the x values that were used
> > during the segfault and write a small script doing just the above with
> > those values, it doesn't segfault.
> > so doing the exact steps (except from the self.measure) in a separate
> > script, i'm unable to trigger the segfault, but the tests always fail.
> >
> > could someone shine some light on why this seems not reproducable
> > outside the test environment?
> >
> > many thanks,
> >
> > stijn
> >
> > --
> > The system will shutdown in 5 minutes.
> >
> > _______________________________________________
> > Scipy-dev mailing list
> > Scipy-dev@scipy.org
> > http://projects.scipy.org/mailman/listinfo/scipy-dev
> >
> 
> 
> 
-- 
The system will shutdown in 5 minutes.



More information about the Scipy-dev mailing list