[Scipy-tickets] [SciPy] #1313: My fight with arpack
SciPy Trac
scipy-tickets@scipy....
Mon Oct 18 17:08:43 CDT 2010
#1313: My fight with arpack
--------------------+-------------------------------------------------------
Reporter: nics | Owner: somebody
Type: defect | Status: new
Priority: normal | Milestone: 0.9.0
Component: Other | Version: 0.8.0
Keywords: |
--------------------+-------------------------------------------------------
Hello everybody,
finally I managed to get through the arpack-testsuite on
Solaris10/SPARC/gcc-4.5.1/scipy-0.8.0/python-2.7
Ther're three issues here; I think there are some dups of them and thus,
the results might be useful for others.
The issues are:
I) Corruption of my holy heap resulting in SIGSEGV/SIGBUS in libc
II) The starting vector of eigen, eigen_symmetric will be overwritten by
arpack making multiple calls with the same starting vector impossible and
this is not very clear to the user.
III) The testsuite's result comparison fail because the results depend
strongly on the starting vector which is random per default.
----
I. My backtrace is:
#0 0xfee570a8 in t_splay () from /lib/libc.so.1
#1 0xfee56f38 in t_delete () from /lib/libc.so.1
#2 0xfee56b4c in realfree () from /lib/libc.so.1
#3 0xfee57348 in _free_unlocked () from /lib/libc.so.1
#4 0xfee57284 in free () from /lib/libc.so.1
#5 0xfed4c1a4 in array_dealloc (self=0x94dd18)
at numpy/core/src/multiarray/arrayobject.c:212
#6 0xff1f0a9c in frame_dealloc (f=0x9c6880) at Objects/frameobject.c:458
#7 0xff2b5660 in tb_dealloc (tb=0x98d698) at Python/traceback.c:28
Utilizing electric fence:
#0 0xff3a0810 in memcpy ()
from /platform/SUNW,SPARC-Enterprise/lib/libc_psr.so.1
#1 0xfca61a5c in ATL_scopy (N=4, X=0xef889efc, incX=<value optimized
out>,
Y=0xef96dff4, incY=<value optimized out>) at ATL_scopy.c:50
#2 0xfe7b6cbc in atl_f77wrap_scopy_ (N=0xffbfa4cc, X=0xef889efc,
INCX=0xf7efa6b0, Y=0xef96dff4, INCY=0xf7efa6b0)
at
/tmp/xas/build/numerics_atlas_lapack_3.8.3_default_gcc_32/src/ATLAS//inte
rfaces/blas/F77/src/f77wrap/ATL_F77wrap_copy.c:114
#3 0xfe7b687c in scopy (n=4, x=..., incx=1, y=..., incy=1)
at
/tmp/xas/build/numerics_atlas_lapack_3.8.3_default_gcc_32/src/ATLAS//inte
rfaces/blas/F77/src/scopy.f:121
#4 0xf7ea5200 in sneupd_ ()
from
/home/myuid/xas/solaris10/python2/python-2.7-ve0-gcc/lib/python2.7/sit
With this information, google has been my friend: Finally I reached here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=572935
The proposed diff fixes the problem. See the attached
02_debian_bug572935.diff for an adjustement to the scipy-0.8.0 source
tree. I've seen others here encountering strange segfaults in libc, too.
----
II.
I've found this point while fixing III. See 03_arpack_copy_v0.diff for a
fix.
----
III.
This had been the hardest issue to find the reason for since I've never
done anything with ARPACK.
What I've got was an InvalidIndexError here:
arpack.py:264 z[:,i] = zr[:,i] + 1.0j * zr[:,i+1]
called (indirectly) from test_nonsymmetric_modes.
The reason is the following: I've got three eigenvalues in d with
imaginary part nonzero.
Why do I get it and you don't:
If you don't give arpack a starting vector, it'll generate a random one
(THIS SHOULD BE DOCUMENTED!) and this influences
- which eigenvalues are returned by ARPACK
- in which order they're returned.
I've written two pure fortran test programs resembling python's ARPACK
usage if you want to verify this (also happens on my Ubuntu Lucid Lynx
x86_64 box).
One should think about fixing that piece of code there in arpack.py
(taking into account the possibility of an odd number of imaginary
eigenvalues). But the testsuite will still fail due to the fact that the
set of eigenvalues returned is not fixed. The solution is to fix them by
giving starting vectors in the testsuite (see
04_arpack_test_always_set_v0.diff)
Regards
Nicolai
--
Ticket URL: <http://projects.scipy.org/scipy/ticket/1313>
SciPy <http://www.scipy.org>
SciPy is open-source software for mathematics, science, and engineering.
More information about the Scipy-tickets
mailing list