Universal OS/X build segfault 11 in arch -i386 mode

[LeeKamentsky]

I am getting a segfault 11 when I do a numpy.frombuffer on a buffer that's not 16-byte aligned when I start Python on the i386 architecture in OS/X. The exact same script works on the 64-bit architecture:

$ arch -i386 python
Python 2.7.6 (v2.7.6:3a1db0d2747e, Nov 10 2013, 00:42:54)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy as np
>>> b = "00"+str(np.arange(20).astype(np.float64).data)
>>> np.version.version
'1.10.0.dev-251acc0'
>>> np.frombuffer(b[2:])
Segmentation fault: 11

and on the 64-bit architecture:

$ python
Python 2.7.6 (v2.7.6:3a1db0d2747e, Nov 10 2013, 00:42:54) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy as np
>>> b = "00"+str(np.arange(20).astype(np.float64).data)
>>> np.version.version
'1.10.0.dev-251acc0'
>>> np.frombuffer(b[2:])
array([  0.,   1.,   2.,   3.,   4.,   5.,   6.,   7.,   8.,   9.,  10.,
    11.,  12.,  13.,  14.,  15.,  16.,  17.,  18.,  19.])

OS/X version is 10.9.
I found this on 1.8.0, tested on 1.9 and master branch with the same result. A colleague reports that 1.7 does not have the problem and that the problem is reproduced on his machine with 1.8.

I am guessing that it's SSE-related since the problem only happens if the buffer size is greater than 32 bytes and that's probably when the conditional code decides to use SSE instead of the regular instructions for copying.

[juliantaylor]

I can't reproduce this on a mac 10.9, how did you build numpy?
there should be no sse involved here, can you produce a backtrace with a debugger?

[LeeKamentsky]

i did pip install originally when I installed 1.8.0 - no build there. On the master branch, I cloned the git repository and did python setup.py build install.

Here's the backtrace:

• thread Misc #1: tid = 0x12c04b, 0x00764cc5 umath.so`DOUBLE_maximum(args=, dimensions=, steps=, __NPY_UNUSED_TAGGEDfunc=0x00000000) + 229 at simd.inc.src:708, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
  • frame #0: 0x00764cc5 umath.soDOUBLE_maximum(args=<unavailable>, dimensions=<unavailable>, steps=<unavailable>, __NPY_UNUSED_TAGGEDfunc=0x00000000) + 229 at simd.inc.src:708 frame #1: 0x007771db umath.soreduce_loop(iter=0x000e48f7, dataptrs=0x01b4b52c, strides=0x01b4b524, countptr=0xbfffdde8, iternext=0x0000000c, needs_api=0, skip_first_count=, data=0x00467a10) + 491 at ufunc_object.c:2783
    frame Deprecation docs #2: 0x0073c390 umath.soPyUFunc_ReduceWrapper(operand=<unavailable>, out=<unavailable>, wheremask=0x00000000, operand_dtype=<unavailable>, result_dtype=<unavailable>, casting=<unavailable>, axis_flags=0x0b470881, reorderable=<unavailable>, keepdims=<unavailable>, subok=<unavailable>, assign_identity=<unavailable>, loop=<unavailable>, data=<unavailable>, buffersize=<unavailable>, funcname=<unavailable>) + 688 at reduction.c:547 frame #3: 0x00776634 umath.soPyUFunc_GenericReduction [inlined] PyUFunc_Reduce(ufunc=, out=, naxes=, odtype=, keepdims=) + 240 at ufunc_object.c:2884
    frame Whitespace cleanup #4: 0x00776544 umath.soPyUFunc_GenericReduction(ufunc=<unavailable>, args=<unavailable>, kwds=<unavailable>, operation=<unavailable>) + 6932 at ufunc_object.c:3854 frame #5: 0x007731e5 umath.soufunc_reduce(ufunc=, args=, kwds=) + 101 at ufunc_object.c:4865
    frame Fix dtype shape comparison #6: 0x000c4230 PythonPyEval_EvalFrameEx + 25344 frame #7: 0x000c6a2c PythonPyEval_EvalCodeEx + 2012
    frame Ravel keyword arg #8: 0x0004022b Pythonfunction_call + 139 frame #9: 0x0000e505 PythonPyObject_Call + 85
    frame Nonzero inconsistency #10: 0x00020b65 Pythoninstancemethod_call + 389 frame #11: 0x0000e505 PythonPyObject_Call + 85
    frame Git dev versioning #12: 0x0007c877 Pythonslot_tp_init + 87 frame #13: 0x000770ea Pythontype_call + 218
    frame Optional out parameter for np.dot() #14: 0x0000e505 PythonPyObject_Call + 85 frame #15: 0x000bf504 PythonPyEval_EvalFrameEx + 5588
    frame Implement half dtype #16: 0x000c6a2c PythonPyEval_EvalCodeEx + 2012 frame #17: 0x000c4825 PythonPyEval_EvalFrameEx + 26869
    frame Speedup the reduce method of the maximum minimum family of ufuncs. #18: 0x000c6a2c PythonPyEval_EvalCodeEx + 2012 frame #19: 0x000c4825 PythonPyEval_EvalFrameEx + 26869
    frame Ticket1559 #20: 0x000c6a2c PythonPyEval_EvalCodeEx + 2012 frame #21: 0x0004022b Pythonfunction_call + 139
    frame Ticket1676 - dtype problem with append_fields #22: 0x0000e505 PythonPyObject_Call + 85 frame #23: 0x000bccbe PythonPyEval_CallObjectWithKeywords + 78
    frame Tickets distutils #24: 0x0058439b multiarray.soarray_repr(self=<unavailable>) + 75 at arrayobject.c:648 frame #25: 0x0005d795 PythonPyObject_Repr + 117
    frame Scalarfromobject bug #26: 0x0005de58 Pythoninternal_print + 328 frame #27: 0x00034eb5 PythonPyFile_WriteObject + 117
    frame Apply patch from ticket #1475. #28: 0x000f2089 Pythonsys_displayhook + 249 frame #29: 0x0000e505 PythonPyObject_Call + 85
    frame Nanfuncs #30: 0x000bccbe PythonPyEval_CallObjectWithKeywords + 78 frame #31: 0x000c3c70 PythonPyEval_EvalFrameEx + 23872
    frame Add 'minlength' keyword to np.bincount (with docs+tests) #32: 0x000c6a2c PythonPyEval_EvalCodeEx + 2012 frame #33: 0x000c6b77 PythonPyEval_EvalCode + 87
    frame [resubmitted] Fix poisson deviate for expected values ~> LONG_MAX #34: 0x000ea9e4 PythonPyRun_InteractiveOneFlags + 372 frame #35: 0x000eac53 PythonPyRun_InteractiveLoopFlags + 99
    frame New iterator #36: 0x000eb5f6 PythonPyRun_AnyFileExFlags + 214 frame #37: 0x00103412 PythonPy_Main + 3410

[juliantaylor]

sure thats the same testcase?
I don't see how frombuffer could call into DOUBLE_maximum

[LeeKamentsky]

not quite the same... it's np.frombuffer(np.zeros(162. np.uint8).data[2:], np.float64). But it should be much the same. I'm debugging it right now, am leaving for the day though, more on it tomorrow.

[juliantaylor]

I found an issue in the reductions not checking the alignment properly, that causes the crash
it wasn't noticed because i386 normally disables sse2, on mac apparently not

but your testcase must be wrong, there is no way maximum is called from ´frombuffer´

[LeeKamentsky]

It had me flummoxed too, the stack trace - I have no idea why it reads that way and I certainly agree with you that the code it says it's executing can't be the code it is executing. But nevertheless, it happened. I just built Numpy, cherry-picking the referenced commit and confirmed, it fixes the problem.

I have to say, your rapid response was great, thanks for fixing the problem. Numpy is at the heart of my project, CellProfiler, which is an open-source tool freely available and designed for biological and medical research and drug discovery. We couldn't have done it without you all.