[SciPy-User] Problem with scipy.special.chebyt

[Pauli Virtanen]

On 2009-08-30, Ivo Maljevic <ivo.maljevic at gmail.com> wrote:
[clip]
> OK, let me know what I can do then to help. For starters, here is the output
> from Mandriva. Keep in mind that I'm using mandriva for the first time in my
> life, so I'm not quite versed in using it:.
>
> I changed the colour to red for the library part.
>
> (gdb) run cheby.py
> Starting program: /usr/bin/python cheby.py
> [Thread debugging using libthread_db enabled]
> [New Thread 0xb7c056c0 (LWP 3763)]
> [ 0.99144486  0.92387953  0.79335334  0.60876143  0.38268343 -0.99144486
>   0.13052619 -0.92387953 -0.13052619 -0.79335334 -0.38268343 -0.60876143]
> det(A)=0.000488281
>
> Program received signal SIGSEGV, Segmentation fault.
> 0xb7e89ed8 in ?? () from /usr/lib/libpython2.6.so.1.0

This probably gets a bit advanced now that the problematic area 
is pinpointed. Some knowledge / willingness to learn 
independently about C and LAPACK/BLAS may be required.

We need to move this discussion to Numpy Trac,

	http://projects.scipy.org/numpy/ticket/1211

so that we don't spam scipy.users list needlessly with this.

    ***

My checklist for the bug would be this -- as I don't know exactly 
what's wrong it's best to check many things and hope to hit 
something:


  Q: Is it really LAPACK or BLAS, and if yes, which one?

- install a different BLAS library, and use 
  "export LD_PRELOAD=/usr/lib/libANOTHERBLAS.so.1"
  to switch to using it. Does the crash persist?
- if you are using an architecture-optimized ATLAS library, try installing
  a less optimized one
- try to recompile LAPACK, and again try to use it. Does the crash persist?
- write a fortran/C-only test case. does it crash, too?


  Q: Are the input parameters to LAPACK sane?

- insert printf statements before and after DGEEV calls in lapack_litemodule.c,
  to print all parameters passed in to DGEEV
- check against lapack manual that the parameters passed to LAPACK are valid
- check that array sizes are large enough
- what does LAPACK report as its lwork? is it sane?
- check if data alignment can be a problem, cf.
  http://projects.scipy.org/numpy/ticket/551
  although I don't really believe this is the problem here.


  Q: Can the crash be traced better?

- insert "print 'PRE'" and "print 'POST'" before and after eig()
- run it under valgrind: are there warnings between PRE/POST?

  Pass --suppressions=valgrind-python.supp to valgrind to 
  suppress some common Python warnings, the suppression file is here:
  http://svn.python.org/projects/python/trunk/Misc/valgrind-python.supp


  Q: Are other things failing, too?

- Try running "numpy.test()" and "scipy.test()".


Other things to do:

- Write this as a suitable regression test in numpy/linalg/tests/test_regression.py
  so that this problem cannot recur silently in future releases.

  Submit it as a patch to be committed to SVN.


-- 
Pauli Virtanen