David Cournapeau wrote:

Lapack 3.2 is problematic, so I would try to downgrade to 3.1.1 first. Which OS are you on ? The exact core you are running, as well as the output of the test suite (numpy.test()) would be helpful,

cheers,

David

Ok, I have downgraded to lapack 3.1.1 and re-compiled and re-installed everything. Numpy test seg faults :( http://pastebin.com/d56fd6e44 This is on Linux (CentOS) and a Quad-Core AMD Opteron(tm) Processor 2350 HE Regards

David Cournapeau wrote:

Not sure it can be considered as progress :) Could you run the test suite with verbosity set to ten (numpy.test(verbose=10)) ?

Also, which fortran compiler are you using ? g77 or gfortran ?

cheers,

David

Ok, http://pastebin.com/ddaae526 Seg faults here -: test_cdouble (test_linalg.TestEigh) I am using gfortran. Regards

Steven Coutts wrote:

Ok, downgraded numpy to 1.2.1 and all the tests pass now!

That's really strange - Linux is the most tested configuration, numpy 1.3.0 should run without problems. There is something unusual with your configuration that I am missing. Could you build numpy 1.3.0 from scratch and paste the output (rm -rf build && python setup.py build &> build.log) ? If you are willing to do it, I would also be interested whether numpy works ok if linked against BLAS/LAPACK instead of atlas (i.e. build numpy, again from scratch, with ATLAS=None python setup.py build, and then run the test suite). cheers, David

David Cournapeau writes: If you are willing to do

it, I would also be interested whether numpy works ok if linked against BLAS/LAPACK instead of atlas (i.e. build numpy, again from scratch, with ATLAS=None python setup.py build, and then run the test suite).

Yes that appears to work fine, all tests run. Regards

David Cournapeau writes:

So that's a problem with ATLAS. Maybe a gcc bug ? Another user contacted me privately for my rpm repository, and got exactly the same problem with the rpms, on CENTOS 5.3 as well. I will try to look at it on a centos VM if I have time this WE,

I think the user who contacted you is the person I am installing this for, he said he had mailed you:) As I said I'm back on numpy 1.2.1 and scipy-0.6.0, anything above that just seg faults or gets the ILAENV error. Think I must have tried nearly every possible combination of versions of packages (including atlas and lapack)! But it's running so it's not a biggy for now. If this were my box I'd give you access to have a bit of a look at, but unfortunately it's not mine. :) Regards

Charles R Harris wrote:

Sounds like this problem might depend on the specific combination of compiler, hardware, and Atlas. Could you tell us which amd chip and compiler versions you are using?

Chuck

processor : 0 vendor_id : AuthenticAMD cpu family : 16 model : 2 model name : Quad-Core AMD Opteron(tm) Processor 2350 HE stepping : 3 cpu MHz : 1994.999 cache size : 512 KB physical id : 0 siblings : 1 core id : 0 cpu cores : 1 fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu de tsc msr pae cx8 apic cmov pat clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext 3dnow constant_tsc rep_good pni cx16 popcnt lahf_lm cmp_legacy extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch bogomips : 3999.28 TLB size : 1024 4K pages clflush size : 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm stc 100mhzsteps hwpstate gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-44) GNU Fortran (GCC) 4.1.2 20080704 (Red Hat 4.1.2-44)

On Sat, Aug 1, 2009 at 1:14 PM, David Cournapeau wrote:

On Fri, Jul 31, 2009 at 8:20 PM, David Cournapeau wrote:

...

Steven Coutts wrote:

...

David Cournapeau writes:

 If you are willing to do

...

it, I would  also be interested whether numpy works ok if linked against BLAS/LAPACK instead of atlas (i.e. build numpy, again from scratch, with ATLAS=None python setup.py build, and then run the test suite).

Yes that appears to work fine, all tests run.

So that's a problem with ATLAS. Maybe a gcc bug ? Another user contacted me privately for my rpm repository, and got exactly the same problem with the rpms, on CENTOS 5.3 as well. I will try to look at it on a centos VM if I have time this WE,

Ok, I have installed CENTOS 5.3 on my machine (kudos to vmware fusion which installs the OS automatically), build numpy 1.3.0 with atlas 3.8.3 + lapack 3.1.1 on 64 bits. But I could not reproduce the bug, unfortunately. Are you using the threaded atlas ?

I forgot: another thing which would be helpful since you can reproduce the bug would be to build a debug version of numpy (python setup.py build_ext -g), and reproduce the bug under gdb to have a traceback. David

Steven Coutts writes:

Ok I have rebuilt numpy-1.3.0 with debugging, and it segfaults as soon as I import numpy in python2.5

Backtrace -: http://pastebin.com/d27fbd2a5

Regards

Sorry ignore this, I cleanded out numpy properly, re-installed 1.3.0 and the tests are all running now. Regards

David Cournapeau wrote:

Do you mean that if you build with debug information, everything else being equal, you cannot reproduce the crashes ?

cheers,

David

That does appear to be the case, SciPy 1.7.0 is now also running fine. Regards

Steven Coutts writes:

Ok, downgraded numpy to 1.2.1 and all the tests pass now!

Regards

But now scipy seg faults straight away http://pastebin.com/de13dd62 Downgraded scipy to 0.7.0 and still the same seg fault :(

David Cournapeau writes:

Make sure your scipy is built against numpy 1.2.1. You cannot build scipy against numpy 1.3.0, and then use scipy with numpy 1.2.1 (but you can build against numpy 1.2.1 and use scipy with numpy 1.3.0).

cheers,

David

Yes it was built against the correct version of Numpy (I triple checked this!) Regards