[SciPy-Dev] SciPy 0.12.0/Numpy 1.7.1 sgerqf segfault
Mon Apr 15 16:13:40 CDT 2013
On 04/13/2013 07:03 AM, Pauli Virtanen wrote:
> 13.04.2013 01:59, Orion Poplawski kirjoitti:
>> runTest (test_interpolate_wrapper.Test) ... ok
>> vtest_ticket_1645 (test_lapack.TestRegression) ... Segmentation fault
>> The segfault may be a python3 bug (http://bugs.python.org/issue17706) trying
>> to handle a lapack error message.
> Thanks, I think there are two issues here:
> (i) Something is wrong with the LAPACK installation. What is the version
> of LAPACK that you have?
ATLAS 3.8.4 plus netlib lapack 3.4.2 (which is where I think sgerqf comes from).
> (ii) The *QR routines are marked as `threadsafe` in flapack.pyf.src,
> which implies releasing the GIL. However, the XERBLA error handling code
> in python_xerbla.c inside Numpy assumes it has the GIL.
> (scipy.linalg doesn't have it's own python_xerbla.c, so it ends up
> looking for the symbol in numpy.linalg.lapack_lite --- rather unexpected!)
So, any suggestions for this? Should flapack.pyf.src not mark them as thread
safe? Should scipy provide its own xerbla?
>> "On entry to SGERQF parameter number 7 had an illegal value"
> Parameter number 7 is LWORK. What is interesting here is that the
> wrapper to this routine ensures that LWORK >= M, as required by LAPACK
> documentation. Stepping through the execution of SGERQF in a debugger
> would reveal what is going wrong.
Unfortunately since this is an atlas wrapped lapack function, I'm losing debug
However, I was able to get it to link in netlib lapack first via
LD_LIBARY_PATH, and -
Breakpoint 3, sgerqf (m=300, n=2, a=..., lda=300, tau=..., work=..., lwork=2,
So lwork is not > M.
#5 0x000000315245f0cc in PyObject_Call (func=func@entry=<fortran at remote
arg=arg@entry=(<numpy.ndarray at remote 0x1196fd0>,),
2082 result = (*call)(func, arg, kw);
Not sure where to look next. Time to move to numpy list?
>> http://www.scipy.org/BugReport seems to not point me anywhere useful.
> 13.04.2013 11:30, Ralf Gommers kirjoitti:
>> No, the page indeed doesn't exist anymore. Maybe it fell victim to a
>> recent spam cleanup.
> Oops, that *is* true. Sorry for my tone in the previous mail...
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane firstname.lastname@example.org
Boulder, CO 80301 http://www.nwra.com
More information about the SciPy-Dev