[SciPy-dev] ***[Possible UCE]*** Re: Another segfault

[Nils Wagner]

On Fri, 03 Mar 2006 15:14:04 -0700
  Travis Oliphant <oliphant at ee.byu.edu> wrote:
> Nils Wagner wrote:
> 
>>On Fri, 03 Mar 2006 14:29:56 -0700
>>  Travis Oliphant <oliphant at ee.byu.edu> wrote:
>>  
>>
>>>David M. Cooke wrote:
>>>
>>>    
>>>
>>>>"Nils Wagner" <nwagner at mecha.uni-stuttgart.de> writes:
>>>>
>>>> 
>>>>
>>>>      
>>>>
>>>>>On a 64 bit machine scipy.test(1,10) results in a 
>>>>>segfault
>>>>>The bt message differs from the bt on a 32 bit machine.
>>>>>For what reason ?
>>>>>
>>>>>Test whether the lu_solve command segfaults, as reported 
>>>>>by NilsUse minimum degree ordering on A'+A.
>>>>>
>>>>>Program received signal SIGSEGV, Segmentation fault.
>>>>>[Switching to Thread 16384 (LWP 5170)]
>>>>>0x00002aaaae34d787 in zpivotL (jcol=0, u=1, 
>>>>>usepr=0x7fffffc62264, perm_r=0xc9c7d0, iperm_r=0xbd8c60,
>>>>>    iperm_c=0xdb55c0, pivrow=0x7fffffc62270, Glu=0x0, 
>>>>>stat=0xffffffffab80bb68) at zpivotL.c:121
>>>>>121             perm_r[*pivrow] = jcol;
>>>>>   
>>>>>
>>>>>        
>>>>>
>>>>btw, I can reproduce this on my 64-bit machine (grr, 
>>>>can't run
>>>>scipy.test() right now because of it).
>>>> 
>>>>
>>>>      
>>>>
>>>I'm wondering if this has to do with the two integer 
>>>arrays that make up 
>>>the csc and csr representations of a sparse matrix.  I'm 
>>>looking for 
>>>where they are checked to make sure they are the right 
>>>type (need to be 
>>>int).  And I'm not finding it.
>>>
>>>-Travis
>>>
>>>
>>>_______________________________________________
>>>Scipy-dev mailing list
>>>Scipy-dev at scipy.net
>>>http://www.scipy.net/mailman/listinfo/scipy-dev
>>>    
>>>
>>
>>
>>No longer a segfault on my 64-bit machine, but
>>======================================================================
>>ERROR: Test whether the lu_solve command segfaults, as 
>>reported by Nils
>>----------------------------------------------------------------------
>>Traceback (most recent call last):
>>   File 
>>"/usr/lib64/python2.4/site-packages/scipy/sparse/tests/test_sparse.py", 
>>line 255, in check_solve
>>     xx = lu_factor(A.tocsc()).solve(r)
>>   File 
>>"/usr/lib64/python2.4/site-packages/scipy/sparse/sparse.py", 
>>line 2518, in lu_factor
>>     diag_pivot_thresh, drop_tol, relax, panel_size)
>>TypeError: colptr and rowind must be of type cint
>>
>>======================================================================
>>ERROR: Test whether the lu_solve command segfaults, as 
>>reported by Nils
>>----------------------------------------------------------------------
>>Traceback (most recent call last):
>>   File 
>>"/usr/lib64/python2.4/site-packages/scipy/sparse/tests/test_sparse.py", 
>>line 255, in check_solve
>>     xx = lu_factor(A.tocsc()).solve(r)
>>   File 
>>"/usr/lib64/python2.4/site-packages/scipy/sparse/sparse.py", 
>>line 1351, in tocsc
>>     return self.tocoo().tocsc()
>>   File 
>>"/usr/lib64/python2.4/site-packages/scipy/sparse/sparse.py", 
>>line 1347, in tocoo
>>     data, col, row = func(self.data, self.colind, 
>>self.indptr)
>>ValueError: failed to create intent(cache|hide)|optional 
>>array-- must have defined dimensions but got (0,)
>>
>>======================================================================
>>ERROR: Test whether the lu_solve command segfaults, as 
>>reported by Nils
>>----------------------------------------------------------------------
>>Traceback (most recent call last):
>>   File 
>>"/usr/lib64/python2.4/site-packages/scipy/sparse/tests/test_sparse.py", 
>>line 255, in check_solve
>>     xx = lu_factor(A.tocsc()).solve(r)
>>   File 
>>"/usr/lib64/python2.4/site-packages/scipy/sparse/sparse.py", 
>>line 2518, in lu_factor
>>     diag_pivot_thresh, drop_tol, relax, panel_size)
>>TypeError: colptr and rowind must be of type cint
>>
>>----------------------------------------------------------------------
>>Ran 1109 tests in 2.124s
>>
>>FAILED (errors=3)
>>
>>  
>>
> 
> Good.  At least two of those errors are due to the 
>explicit check I put 
> in there.  Now, we just have to figure out why the index 
>pointers are of 
> the wrong type (they need to be of type int).  Notice, 
>that this means 
> we are limiting our matrix sizes to
> 
> 2^31 x 2^31
> 
> even for 64-bit machines.   
> 
> -Travis
> 
> 
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-dev

  
Travis,

On a 32 bit machine I obtain with

gdb --exec=python
GNU gdb 6.3
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 "i586-suse-linux".
(gdb) r 
/usr/local/lib/python2.4/site-packages/scipy/sparse/sparse.py
Starting program: /usr/local/bin/python 
/usr/local/lib/python2.4/site-packages/scipy/sparse/sparse.py

snip
Solve: single precision complex:
Solve: double precision complex:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1076175008 (LWP 31853)]
0x08081cdb in ?? ()
(gdb) bt
#0  0x08081cdb in ?? ()
#1  0x4265913c in ?? ()
    from 
/usr/local/lib/python2.4/site-packages/scipy/sparse/_csuperlu.so
#2  0x081b7118 in ?? ()
#3  0xbfffe5b8 in ?? ()
#4  0x420c2fa9 in superlu_python_module_free 
(ptr=0x4038c34c) at _superlu_utils.c:61
#5  0x420c2fa9 in superlu_python_module_free 
(ptr=0x81b7118) at _superlu_utils.c:61
#6  0x420d734f in Destroy_SuperMatrix_Store (A=0x4038c34c) 
at util.c:56
#7  0x420c2db6 in Py_cgssv (self=0x0, args=0x4029de2c, 
kwdict=0x0)
     at _csuperlumodule.c:99
#8  0x0811eb56 in ?? ()
#9  0x00000000 in ?? ()
#10 0x4029de2c in ?? ()
#11 0x00000000 in ?? ()
#12 0x00000003 in ?? ()
#13 0xffffffff in ?? ()
#14 0x405b8240 in ?? ()
#15 0x420c2a60 in Py_cgstrf () at _csuperlumodule.c:163
#16 0x080c74ed in ?? ()
#17 0x4037f3ac in ?? ()
#18 0x4029de2c in ?? ()
#19 0x00000000 in ?? ()
#20 0x0814d940 in ?? ()
#21 0x0000000b in ?? ()
#22 0x2a080909 in ?? ()
#23 0x4035735c in ?? ()
#24 0x4038c40c in ?? ()
#25 0x4064bd60 in _PyCLongDouble_ArrFuncs ()
    from 
/usr/local/lib/python2.4/site-packages/numpy/core/multiarray.so

Can you reproduce this ?

Nils