I'm seeing a segfault running the scipy 0.12 tests against numpy 1.7.1 with python 3.3.1.  The crash is here:

test_ticket_1645 (test_lapack.TestRegression) ... 
Program received signal SIGSEGV, Segmentation fault.
PyErr_SetObject (exception=exception@entry=<type at remote 0x3032fface0>, 
    value=value@entry='On entry to SGERQF parameter number 7 had an illegal value')
    at /usr/src/debug/Python-3.Python/errors.c:67
67          exc_value = tstate->exc_value;
(gdb) print tstate
$1 = (PyThreadState *) 0x0

So it appears that PyThreadState_GET() is returning NULL and PyErr_SetOject() is not handling that condition.  Not sure if this is a sign of another issue.

(gdb) bt
#0  PyErr_SetObject (exception=exception@entry=<type at remote 0x7ffff7f75ce0>, 
    value=value@entry='On entry to SGERQF parameter number 7 had an illegal value')
    at /usr/src/debug/Python-3.Python/errors.c:67
#1  0x00007ffff7c93bbf in PyErr_SetString (exception=<type at remote 0x7ffff7f75ce0>, 
    string=string@entry=0x7fffffff8160 "On entry to SGERQF parameter number 7 had an illegal value") at /usr/src/debug/Python-3.Python/errors.c:125
#2  0x00007fffeea223f1 in xerbla_ (srname=<optimized out>, info=<optimized out>)
    at numpy/linalg/python_xerbla.c:35
#3  0x00007fffee4925d9 in sgerqf_ () from /usr/lib64/atlas/liblapack.so.3
#4  0x00007fffe6d5a56f in f2py_rout__flapack_sgerqf ()
   from /scratch/orion/redhat/BUILDROOT/scipy-0.12.0-1.fc20.x86_64/usr/lib64/python3.3/site-packages/scipy/linalg/_flapack.cpython-33m.so
#5  0x00007ffff7bda0cc in PyObject_Call (func=func@entry=<fortran at remote 0x7fffebddc198>, 
    arg=arg@entry=(<numpy.ndarray at remote 0x11a60e0>,), kw=kw@entry={'lwork': 2})
    at /usr/src/debug/Python-3.Objects/abstract.c:2082
#6  0x00007ffff7c859b2 in ext_do_call (nk=<optimized out>, na=<optimized out>, 
    flags=<optimized out>, pp_stack=0x7fffffff85f8, func=<fortran at remote 0x7fffebddc198>)
    at /usr/src/debug/Python-3.Python/ceval.c:4406
#7  PyEval_EvalFrameEx (
    f=f@entry=Frame 0x11ae310, for file /usr/lib64/python3.3/unittest/case.py, line 173, in handle (self=<_AssertRaisesContext(test_case=<Dummy(_testMethodName='nop', _cleanups=[], _testMethodDoc=None, _outcomeForDoCleanups=None, _type_equality_funcs={<type at remote 0x7ffff7f8b800>: 'assertMultiLineEqual', <type at remote 0x7ffff7f7d920>: 'assertListEqual', <type at remote 0x7ffff7f80440>: 'assertDictEqual', <type at remote 0x7ffff7f85560>: 'assertTupleEqual', <type at remote 0x7ffff7f843c0>: 'assertSetEqual', <type at remote 0x7ffff7f84220>: 'assertSetEqual'}) at remote 0x7fffecd1c390>, msg=None, obj_name='<fortran object>', expected=<type at remote 0x7ffff7f799c0>, expected_regex=None) at remote 0x7fffe0716cd0>, name='assertRaises', callable_obj=<fortran at remote 0x7fffebddc198>, args=(<numpy.ndarray at remote 0x11a60e0>,), kwargs={'lwork': 2}), 
    throwflag=throwflag@entry=0) at /usr/src/debug/Python-3.Python/ceval.c:2744
#8  0x00007ffff7c879cc in fast_function (nk=<optimized out>, na=5, n=5, 
    pp_stack=0x7fffffff8770, func=<optimized out>)
    at /usr/src/debug/Python-3.Python/ceval.c:4179
#9  call_function (oparg=<optimized out>, pp_stack=0x7fffffff8770)
    at /usr/src/debug/Python-3.Python/ceval.c:4112
..............

it goes on a long ways down.

What is xerbla? PyThreadState_GET() returning NULL means the GIL has been released, sounds like a bug in a third-party C extension.

Yes, this is a bug in numpy.linalg --- the GIL is released but the error handling code assumes it's not. The error doesn't appear with in typical LAPACK installations, so this code branch was missed.

Thank you, closing then.

Despite numpy not calling the library properly, it stills seems to me that python should not segfault due to not handling a null pointer.  But thanks for the help.