[Scipy-tickets] [SciPy] #1496: segfaults on OS X Lion

SciPy Trac scipy-tickets@scipy....
Thu Aug 18 05:42:29 CDT 2011


#1496: segfaults on OS X Lion
--------------------------+-------------------------------------------------
 Reporter:  rgommers      |       Owner:  cdavid     
     Type:  defect        |      Status:  new        
 Priority:  normal        |   Milestone:  Unscheduled
Component:  Build issues  |     Version:  0.9.0      
 Keywords:  OS X Lion     |  
--------------------------+-------------------------------------------------
 #1476 (building on OS X Lion) was fixed for everyone except cshimmin.  So
 opening a ticket for his issue. Quoting all relevant comments he made
 below:

 It looks like the updated gfortran binary from r.research.att.com has made
 its way into homebrew. With the new binary and adding complex.h to the
 files indicated by @rsenk330, scipy installs successfully.

 However, when I run scipy.test() from ipython, I get the following sever
 error, causing python to abort:
 {{{
 In [1]: import scipy
 In [2]: scipy.test('full')
 Running unit tests for scipy
 NumPy version 1.6.1
 NumPy is installed in /usr/local/Cellar/python/2.7.2/lib/python2.7/site-
 packages/numpy
 SciPy version 0.9.0
 SciPy is installed in /usr/local/Cellar/python/2.7.2/lib/python2.7/site-
 packages/scipy
 Python version 2.7.2 (default, Jun 29 2011, 14:53:31) [GCC 4.2.1 (Apple
 Inc. build 5666) (dot 3)]
 nose version 1.0.0
 ................................................................................
 ................................................................................
 ....F.FFpython(33717) malloc: *** error for object 0x103b584b0: pointer
 being freed was not allocated
 *** set a breakpoint in malloc_error_break to debug
 Abort trap: 6
 }}}

 I am seeing at least 4 different failure modes. I have just compiled a
 fresh copy of scipy 0.9.0 from PyPI (after adding patching in the #include
 <complex.h> lines discussed here.)

 Here's the (top-truncated) output from a couple of runs of
 scipy.test(verbose=2):
 {{{
 test_djbfft (test_basic.TestDoubleFFT) ... ok
 test_n_argument_real (test_basic.TestDoubleFFT) ... ok
 test_definition (test_basic.TestDoubleIFFT) ... FAIL
 test_definition_real (test_basic.TestDoubleIFFT) ... ok
 test_djbfft (test_basic.TestDoubleIFFT) ... FAIL
 test_random_complex (test_basic.TestDoubleIFFT) ... FAIL
 python(80905,0x7fff77bdc960) malloc: *** error for object 0x1055a2320:
 pointer being freed was not allocated
 *** set a breakpoint in malloc_error_break to debug
 Abort trap: 6
 }}}
 {{{
 test_djbfft (test_basic.TestDoubleFFT) ... ok
 test_n_argument_real (test_basic.TestDoubleFFT) ... ok
 test_definition (test_basic.TestDoubleIFFT) ... FAIL
 test_definition_real (test_basic.TestDoubleIFFT) ... ok
 test_djbfft (test_basic.TestDoubleIFFT) ... FAIL
 test_random_complex (test_basic.TestDoubleIFFT) ... FAIL
 test_random_real (test_basic.TestDoubleIFFT) ... FAIL
 test_size_accuracy (test_basic.TestDoubleIFFT) ... Segmentation fault: 11
 }}}
 Another failure mode I saw included a warning (sorry, didn't catch this
 one with verbosity):
 {{{
 ........................................
 ........................................
 ........................................
 ............................./usr/local/Cellar/python/2.7.2/lib/python2.7
 /site-packages/scipy/cluster/vq.py:582: UserWarning: One of the clusters
 is empty. Re-run kmean with a different initialization.
   warnings.warn("One of the clusters is empty. "
 ...............F.FFpython(80891,0x7fff77bdc960) malloc: *** error for
 object 0x10590a820: pointer being freed was not allocated
 *** set a breakpoint in malloc_error_break to debug
 Abort trap: 6
 }}}
 Finally, in the last failure mode I have observed when running
 scipy.test(), the python interpreter hangs at 100% cpu, and doesn't
 respond to sigint. It died silently upon sigterm though.

 I'm guessing at least some of this non-deterministic behavior is from the
 test_random_* functions, but I haven't spent time looking into this.

 Let me know if any additional information can help.

 Just to be clear: although the failure modes seem non-deterministic, I
 should mention that I have never run test() successfully; the farthest I
 have seen it get is to "test_definition ... Segmentation fault 11".

 And as a bonus, here are 2 new failures that I just observed:
 {{{
 test_djbfft (test_basic.TestDoubleFFT) ... ok
 test_n_argument_real (test_basic.TestDoubleFFT) ... ok
 test_definition (test_basic.TestDoubleIFFT) ... FAIL
 test_definition_real (test_basic.TestDoubleIFFT) ... ok
 test_djbfft (test_basic.TestDoubleIFFT) ... FAIL
 test_random_complex (test_basic.TestDoubleIFFT) ... Bus error: 10
 }}}
 {{{
 test_djbfft (test_basic.TestDoubleFFT) ... ok
 test_n_argument_real (test_basic.TestDoubleFFT) ... ok
 test_definition (test_basic.TestDoubleIFFT) ... FAIL
 test_definition_real (test_basic.TestDoubleIFFT) ... ok
 test_djbfft (test_basic.TestDoubleIFFT) ... FAIL
 test_random_complex (test_basic.TestDoubleIFFT) ... FAIL
 test_random_real (test_basic.TestDoubleIFFT) ... FAIL
 python(80972,0x7fff77bdc960) malloc: *** error for object 0x1054c7028:
 incorrect checksum for freed object - object was probably modified after
 being freed.
 *** set a breakpoint in malloc_error_break to debug
 Abort trap: 6
 }}}

-- 
Ticket URL: <http://projects.scipy.org/scipy/ticket/1496>
SciPy <http://www.scipy.org>
SciPy is open-source software for mathematics, science, and engineering.


More information about the Scipy-tickets mailing list