Errors in single-precision BLAS (libatlas3gf-sse)

Bug #363510 reported by Pauli Virtanen
This bug affects 5 people
Affects Status Importance Assigned to Milestone
atlas (Debian)
Fix Released
atlas (Ubuntu)
Fix Released
Morten Kjeldgaard

Bug Description

At least the single-precision complex arithmetic in libatlas3gf-sse 3.6.0-22ubuntu2 yields completely invalid results. A test program demonstrating the errors is attached.

This issue appears to be specific to the SSE version of Atlas.

Would it be possible to add some sanity checks to Ubuntu/Debian's Atlas build, so that this type of problems would be detected and hosed packages wouldn't make it into distribution? Atlas is an important component in many scientific applications, and bugs in the shipped version will affect many programs down the stream.


Example of output from the simple test program on this platform:

$ gfortran -o test test.f -lblas
$ ldd test => (0xffffe000) => /usr/lib/sse/atlas/ (0xb7bc6000) => /usr/lib/ (0xb7b12000) => /lib/tls/i686/cmov/ (0xb7aec000) => /lib/ (0xb7add000) => /lib/tls/i686/cmov/ (0xb797a000)
 /lib/ (0xb7fb8000)
$ ./test # this uses libatlas3gf-sse 3.6.0-22ubuntu2
 - complex*8: ( 4.0000000 , 6.9998479 )
 - complex*16: ( -4.0000000000000000 , 12.000000000000000 )
$ LD_PRELOAD=/usr/lib/ ./test # use refblas3 1.2-8ubuntu2
$ LD_PRELOAD=/usr/lib/atlas/ ./test # use libatlas3gf-base 3.6.0-22ubuntu2

ProblemType: Bug
Architecture: i386
DistroRelease: Ubuntu 9.04
NonfreeKernelModules: nvidia
Package: libatlas3gf-sse 3.6.0-22ubuntu2
 PATH=(custom, user)
SourcePackage: atlas
Uname: Linux 2.6.28-11-generic i686

Related branches

Revision history for this message
Pauli Virtanen (pauli-virtanen) wrote :
Revision history for this message
Eric Firing (efiring) wrote :

I have confirmed the bug on my 9.04 rc system, upgraded yesterday from 8.10. I get the failure with Pauli's test program. I ran into the problem when I tried to build numpy from svn--it failed nosetests using complex variables in linalg. I routinely built from svn using 8.10, with no such problem. This is puzzling because it looks like the atlas library has not been recompiled since 2004.

I'm using libatlas3gf-sse2 package.

Revision history for this message
Eric Firing (efiring) wrote :

I installed the libatlas-test package, ran the tests, and found two that failed: xzl2blastst and xcl2blastst. Output is attached.

Revision history for this message
Matthew Arnold (matthew-arnold-1) wrote :

This also affects SSE2... I suppose I should also file a report there.

Essentially the same problems as above:
fails on the jaunty version, ok for intrepid
xzl2blastst & zcl2blastst fail
propagates all the way up to numpy/scipy

Revision history for this message
Andrew Straw (astraw) wrote :

This is still present me on a Karmic i386 sbuild. Steps to reproduce ("failure" will be printed):

sudo apt-get install gfortran libatlas-sse2-dev
gfortran -o test test.f -lblas

Morten Kjeldgaard (mok0)
Changed in atlas (Ubuntu):
assignee: nobody → Morten Kjeldgaard (mok0)
Revision history for this message
Scott Howard (showard314) wrote :

similar upstream bug with xcl2blastst test libatlas-test (3.6.0-24) failure

Changed in atlas (Debian):
status: Unknown → New
Changed in atlas (Ubuntu):
status: New → Confirmed
Revision history for this message
Pauli Virtanen (pauli-virtanen) wrote :

This seems to be fixed in David C's PPA Atlas packages (the jaunty versions install also on karmic):

Revision history for this message
Andrew Straw (astraw) wrote :

This is still a problem on lucid i386 with atlas 3.6.0-24ubuntu1.

Revision history for this message
Sylvestre Ledru (sylvestre) wrote :

FYI, this bug is fixed with Debian Experimental ATLAS packages.

Revision history for this message
Morten Kjeldgaard (mok0) wrote :

I am building atlas version 3.8.3-13 from exp. as we speak. However, the build takes so long, that I might as well make use of the time to comment while it's compiling.

libatlas3gf-base has a huge list of dependencies, which is probably why atlas 3.8.3 is still in experimental(?) It is a major step to upgrade this library so late in the Lucid cycle. That said, everyone would be _very_ pleased to see this bug closed!

I have discussed a bit with ScottK on IRC, and our approach so far is the following: we need to test packages that are run time depends and not build depends. If this goes well, we can move forward and test some of the build depends. If that goes well...

Sylvestre, is there anything more you can tell us?

Morten Kjeldgaard (mok0)
Changed in atlas (Ubuntu):
importance: Undecided → Medium
Revision history for this message
David Cournapeau (cournape) wrote :

This is a major issue - if upgrading to experimental packages is not possible, the next best solution would be to remove the sse/sse2 packages from the repository. This is especially important for Lucid because it is a LTS.

Revision history for this message
Keenan Pepper (keenanpepper) wrote :

Why is this only medium importance? This makes octave, numpy, etc. totally unreliable for simple matrix operations. I thought I was going crazy because the octave "*" operator wasn't acting associatively.

Changed in atlas (Debian):
status: New → Fix Released
Revision history for this message
Pauli Virtanen (pauli-virtanen) wrote :

Seems to be finally fixed in the 3.8.3-22ubuntu2 packages in Maverick.

Felix Geyer (debfx)
Changed in atlas (Ubuntu):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.