[SciPy-dev] lstsq segfaults for scipy 0.9.5, numpy 0.9.5 on python 2.3

[Nils Wagner]

On Tue, 21 Mar 2006 14:00:08 -0500
  "Albert Huang" <ashuang at gmail.com> wrote:
> Hi,
> 
> I'm using numpy 0.9.5 and scipy 0.9.5 with python 2.3 on 
>a debian (unstable)
> system
> 
> scipy.linalg.lstsq segfaults when I run this program:
> 
> file:  testlstsq.py
> ----
> from numpy import *
> from scipy.linalg import lstsq
> 
> a = array( ((1,1), (1.1,0.9), (0.9,1.1), (0.8,1.2)) )
> b = array( (2,2,2,2) )
> 
> print lstsq(a,b)
> ----
> 
> 
> 
> stack trace:
> # gdb python
> GNU gdb 6.3-debian
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public 
>License, and you are
> welcome to change it and/or distribute copies of it 
>under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show 
>warranty" for details.
> This GDB was configured as "i386-linux"...(no debugging 
>symbols found)
> Using host libthread_db library 
>"/lib/tls/libthread_db.so.1".
> 
> (gdb) run testlstsq.py
> Starting program: /usr/bin/python testlstsq.py
> (no debugging symbols found)
> (no debugging symbols found)
> [Thread debugging using libthread_db enabled]
> [New Thread -1209723200 (LWP 32526)]
> (no debugging symbols found)
> (no debugging symbols found)
> (no debugging symbols found)
> (no debugging symbols found)
> (no debugging symbols found)
> (no debugging symbols found)
> (no debugging symbols found)
> (no debugging symbols found)
> 
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread -1209723200 (LWP 32526)]
> 0x08089aab in PyType_IsSubtype ()
> (gdb) where
> #0  0x08089aab in PyType_IsSubtype ()
> #1  0xb7cd4941 in PyUFunc_GenericReduction 
>(self=0x819aa20, args=0xb6c1d2ac,
> 
>    kwds=0x0, operation=0) at ufuncobject.c:2388
> #2  0x08058c4e in PyObject_Call ()
> #3  0xb7d14d2a in PyArray_GenericReduceFunction 
>(m1=0x828ed78, op=0x819aa20,
> 
>    axis=Variable "axis" is not available.
> ) at arrayobject.c:2465
> #4  0xb7d2151b in PyArray_All (self=0x8, axis=1)
>    at numpy/core/src/multiarraymodule.c:617
> #5  0xb6d0cde7 in array_from_pyobj (type_num=12, 
>dims=0xbf8ee02c, rank=1,
>    intent=12, obj=0x8113500) at 
>build/src/fortranobject.c:523
> #6  0xb6cf3012 in f2py_rout_flapack_dgelss 
>(capi_self=0xb77627e8,
>    capi_args=0xb6dde4cc, capi_keywds=0xb6c1ecec,
>    f2py_func=0xb7281d40 <dgelss_>)
>    at 
>build/src/build/src/Lib/lib/lapack/flapackmodule.c:2896
> #7  0xb6d0c671 in fortran_call (fp=0xb77627e8, 
>arg=0xb6dde4cc,
> kw=0xb6c1ecec)
>    at build/src/fortranobject.c:267
> #8  0x08058c4e in PyObject_Call ()
> #9  0x080b437f in PyEval_GetFuncName ()
> #10 0x080b8417 in PyEval_EvalCodeEx ()
> #11 0x080b6b64 in PyEval_GetFuncName ()
> #12 0x080b8417 in PyEval_EvalCodeEx ()
> #13 0x080b8695 in PyEval_EvalCode ()
> #14 0x080d935c in PyRun_FileExFlags ()
> #15 0x080d9623 in PyRun_SimpleFileExFlags ()
> #16 0x08054fc7 in Py_Main ()
> #17 0xb7e67ed0 in __libc_start_main () from 
>/lib/tls/libc.so.6
> #18 0x080549a1 in _start ()
> 
> 
> Any suggestions?
> -albert

I cannot reproduce it here.
(array([ 1.,  1.]), 1.4849602282430439e-32, 2, array([ 
2.83200503,  0.31582825]))
>>> scipy.__version__
'0.4.9.1742'
>>> numpy.__version__
'0.9.7.2257'

Nils