![](https://secure.gravatar.com/avatar/2fc72f90fcc62f5acff935c801a98447.jpg?s=120&d=mm&r=g)
import numpy numpy.test() Running unit tests for numpy NumPy version 1.2.1 NumPy is installed in /usr/local/nonsystem/simpson/lib/python2.5/site-
Having built an up to date lapack and ATLAS against gcc 4.3.2, I tried installing numpy 1.2.1 on Python 2.5.4. When testing I get: Python 2.5.4 (r254:67916, Jan 24 2009, 00:27:20) [GCC 4.3.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. packages/numpy Python version 2.5.4 (r254:67916, Jan 24 2009, 00:27:20) [GCC 4.3.2] nose version 0.10.4 ..........................................................................................................................................................................................................................................................................................................................................................................................................................................F ................K ........................................................................ ........................................................................ ................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................*** glibc detected *** python: free(): invalid next size (fast): 0x000000001196b550 *** I then have to kill python to get control again. -gideon
![](https://secure.gravatar.com/avatar/9820b5956634e5bbad7f4ed91a232822.jpg?s=120&d=mm&r=g)
Gideon Simpson wrote:
Having built an up to date lapack and ATLAS against gcc 4.3.2, I tried installing numpy 1.2.1 on Python 2.5.4. When testing I get:
import numpy numpy.test() Running unit tests for numpy NumPy version 1.2.1 NumPy is installed in /usr/local/nonsystem/simpson/lib/python2.5/site-
Python 2.5.4 (r254:67916, Jan 24 2009, 00:27:20) [GCC 4.3.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. packages/numpy Python version 2.5.4 (r254:67916, Jan 24 2009, 00:27:20) [GCC 4.3.2] nose version 0.10.4 ..........................................................................................................................................................................................................................................................................................................................................................................................................................................F ................K ........................................................................ ........................................................................ ................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................*** glibc detected *** python: free(): invalid next size (fast): 0x000000001196b550 ***
Can you rerun the test verbosely ? python -c "import numpy; numpy.test(verbose=10)" This glibc message is generally a symptom of serious memory corruption - which is why only the OS can stop it at that point. cheers, David
![](https://secure.gravatar.com/avatar/2fc72f90fcc62f5acff935c801a98447.jpg?s=120&d=mm&r=g)
Rerunning the tests with verbosity, it dies at: test_single (test_linalg.TestSolve) ... ok Ticket #652 ... *** glibc detected *** python: free(): invalid next size (fast): 0x0000000001e284e0 *** I'm using ATLAS 3.8.2 and lapack 3.2. ATLAS and lapack were all built with the -m64 flag. -gideon On Jan 24, 2009, at 11:37 PM, David Cournapeau wrote:
Gideon Simpson wrote:
Having built an up to date lapack and ATLAS against gcc 4.3.2, I tried installing numpy 1.2.1 on Python 2.5.4. When testing I get:
import numpy numpy.test() Running unit tests for numpy NumPy version 1.2.1 NumPy is installed in /usr/local/nonsystem/simpson/lib/python2.5/ site-
Python 2.5.4 (r254:67916, Jan 24 2009, 00:27:20) [GCC 4.3.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. packages/numpy Python version 2.5.4 (r254:67916, Jan 24 2009, 00:27:20) [GCC 4.3.2] nose version 0.10.4 ..........................................................................................................................................................................................................................................................................................................................................................................................................................................F ................K ........................................................................ ........................................................................ ................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................*** glibc detected *** python: free(): invalid next size (fast): 0x000000001196b550 ***
Can you rerun the test verbosely ?
python -c "import numpy; numpy.test(verbose=10)"
This glibc message is generally a symptom of serious memory corruption - which is why only the OS can stop it at that point.
cheers,
David
_______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
![](https://secure.gravatar.com/avatar/9820b5956634e5bbad7f4ed91a232822.jpg?s=120&d=mm&r=g)
Gideon Simpson wrote:
Rerunning the tests with verbosity, it dies at:
test_single (test_linalg.TestSolve) ... ok Ticket #652 ... *** glibc detected *** python: free(): invalid next size (fast): 0x0000000001e284e0 ***
I'm using ATLAS 3.8.2 and lapack 3.2.
Lapack 3.2 may be the problem. There have been interface changes in some functions related to LU factorization in LAPACK 3.2 - I am not sure that those are the ones used by eig, but since many people have run the test suite with numpy 1.2.1 and atlas 3.8.2, I would look at that first. cheers, David
![](https://secure.gravatar.com/avatar/764323a14e554c97ab74177e0bce51d4.jpg?s=120&d=mm&r=g)
On Sat, Jan 24, 2009 at 22:47, Gideon Simpson <simpson@math.toronto.edu> wrote:
Having built an up to date lapack and ATLAS against gcc 4.3.2, I tried installing numpy 1.2.1 on Python 2.5.4. When testing I get:
Run numpy.test(verbose=2) in order to have nose print out the name of the method it is running before actually running it. This will let us figure out which test is causing the failure. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
![](https://secure.gravatar.com/avatar/33da4070356fc5206a334ed1e82d60b8.jpg?s=120&d=mm&r=g)
Not sure what the problem is in your case, but I had the same error a while back. For some reason, ATLAS thought it should be compiled as 64 bit but numpy as 32 bit. . It went away after I passed the -b 32 flag to configure in ATLAS (I think). Thus that's one thing to check. Also, make sure you're using ATLAS 3.8.x, as I had problems with the 3.9 series (don't know if that would be an issue still). --Hoyt On Sat, Jan 24, 2009 at 8:47 PM, Gideon Simpson <simpson@math.toronto.edu> wrote:
Having built an up to date lapack and ATLAS against gcc 4.3.2, I tried installing numpy 1.2.1 on Python 2.5.4. When testing I get:
import numpy numpy.test() Running unit tests for numpy NumPy version 1.2.1 NumPy is installed in /usr/local/nonsystem/simpson/lib/python2.5/site-
Python 2.5.4 (r254:67916, Jan 24 2009, 00:27:20) [GCC 4.3.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. packages/numpy Python version 2.5.4 (r254:67916, Jan 24 2009, 00:27:20) [GCC 4.3.2] nose version 0.10.4 ..........................................................................................................................................................................................................................................................................................................................................................................................................................................F ................K ........................................................................ ........................................................................ ................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................*** glibc detected *** python: free(): invalid next size (fast): 0x000000001196b550 ***
I then have to kill python to get control again. -gideon
_______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
-- ++++++++++++++++++++++++++++++++++++++++++++++++ + Hoyt Koepke + University of Washington Department of Statistics + http://www.stat.washington.edu/~hoytak/ + hoytak@gmail.com ++++++++++++++++++++++++++++++++++++++++++
![](https://secure.gravatar.com/avatar/9820b5956634e5bbad7f4ed91a232822.jpg?s=120&d=mm&r=g)
Hoyt Koepke wrote:
Not sure what the problem is in your case, but I had the same error a while back. For some reason, ATLAS thought it should be compiled as 64 bit but numpy as 32 bit. . It went away after I passed the -b 32 flag to configure in ATLAS (I think). Thus that's one thing to check. Also, make sure you're using ATLAS 3.8.x, as I had problems with the 3.9 series (don't know if that would be an issue still).
Actually, I would advise using only 3.8.2. Previous versions had bugs for some core routines used by numpy (at least 3.8.0 did). I am a bit surprised that a 64 bits-built atlas would be runnable at all in a 32 bits binary - I would expect the link phase to fail if two different object formats are linked together. cheers, David
![](https://secure.gravatar.com/avatar/0b0cdb149c8a423545249acb0d0001d1.jpg?s=120&d=mm&r=g)
David Cournapeau wrote:
Hoyt Koepke wrote:
<SNIP>
Actually, I would advise using only 3.8.2. Previous versions had bugs for some core routines used by numpy (at least 3.8.0 did). I am a bit surprised that a 64 bits-built atlas would be runnable at all in a 32 bits binary - I would expect the link phase to fail if two different object formats are linked together.
Linking 32 and 64 bit ELF objects together in an extension will fail on any system but OSX where the ld will happily link together anything. Since that linker also does missing symbol lookup at runtime you will see some surprising distutils bugs when you thought that the build went perfectly, i.e. scipy 0.6 would not use the fortran compiler I would tell it to use, but one extension would use gfortran instead of sage_fortran when it was available in $PATH. sage_fortran would would just inject an "-m64" into the options and call gfortran. But with a few fortran objects being 32 bit some extensions in scipy would fail to import and it took me quite a while to track this one down. I haven't had time to test 0.7rc2 yet, but hopefully will do so in the next day or two.
cheers,
David
Cheers, Michael
_______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
![](https://secure.gravatar.com/avatar/2fc72f90fcc62f5acff935c801a98447.jpg?s=120&d=mm&r=g)
Rebuilding the library against ATLAS 3.8.2 with lapack 3.1.1 seems to have done the trick. I do get one failure: ====================================================================== FAIL: test_umath.TestComplexFunctions.test_against_cmath ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/nonsystem/simpson/lib/python2.5/site-packages/nose/ case.py", line 182, in runTest self.test(*self.arg) File "/usr/local/nonsystem/simpson/lib/python2.5/site-packages/ numpy/core/tests/test_umath.py", line 268, in test_against_cmath assert abs(a - b) < atol, "%s %s: %s; cmath: %s"%(fname,p,a,b) AssertionError: arcsinh -2j: (-1.31695789692-1.57079632679j); cmath: (1.31695789692-1.57079632679j) ---------------------------------------------------------------------- -gideon On Jan 25, 2009, at 5:46 AM, Michael Abshoff wrote:
David Cournapeau wrote:
Hoyt Koepke wrote:
<SNIP>
Actually, I would advise using only 3.8.2. Previous versions had bugs for some core routines used by numpy (at least 3.8.0 did). I am a bit surprised that a 64 bits-built atlas would be runnable at all in a 32 bits binary - I would expect the link phase to fail if two different object formats are linked together.
Linking 32 and 64 bit ELF objects together in an extension will fail on any system but OSX where the ld will happily link together anything. Since that linker also does missing symbol lookup at runtime you will see some surprising distutils bugs when you thought that the build went perfectly, i.e. scipy 0.6 would not use the fortran compiler I would tell it to use, but one extension would use gfortran instead of sage_fortran when it was available in $PATH. sage_fortran would would just inject an "-m64" into the options and call gfortran. But with a few fortran objects being 32 bit some extensions in scipy would fail to import and it took me quite a while to track this one down. I haven't had time to test 0.7rc2 yet, but hopefully will do so in the next day or two.
cheers,
David
Cheers,
Michael
_______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
![](https://secure.gravatar.com/avatar/da3a0a1942fbdc5ee9a9b8115ac5dae7.jpg?s=120&d=mm&r=g)
Sun, 25 Jan 2009 10:44:15 -0500, Gideon Simpson wrote:
Rebuilding the library against ATLAS 3.8.2 with lapack 3.1.1 seems to have done the trick. I do get one failure:
====================================================================== FAIL: test_umath.TestComplexFunctions.test_against_cmath ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/nonsystem/simpson/lib/python2.5/site-packages/nose/ case.py", line 182, in runTest self.test(*self.arg) File "/usr/local/nonsystem/simpson/lib/python2.5/site-packages/ numpy/core/tests/test_umath.py", line 268, in test_against_cmath assert abs(a - b) < atol, "%s %s: %s; cmath: %s"%(fname,p,a,b) AssertionError: arcsinh -2j: (-1.31695789692-1.57079632679j); cmath: (1.31695789692-1.57079632679j)
Same as http://scipy.org/scipy/numpy/ticket/977, fixed in trunk. -- Pauli Virtanen
participants (6)
-
David Cournapeau
-
Gideon Simpson
-
Hoyt Koepke
-
Michael Abshoff
-
Pauli Virtanen
-
Robert Kern