Open numpy-gitbot opened 11 years ago
Attachment added by trac user Zbyszek_Szmek on 2008-02-28: pythonxerbla.diff
atmention:pearu wrote on 2008-04-09
The idea of fixing the error looks good to me (I have not tested it though).
atmention:pearu wrote on 2008-04-09
Applied modified patch in r4997.
The error handling code is effective when using unoptimized lite lapack shipped with numpy -- tested.
The code should be effective also when system/user provided lapack library does not define xerbla_ symbol -- untested. (if it does not work then (a fix follows!) one needs to build pythonxerbla.c to a library and force it to appear after the lapack libraries in the linking command).
Theoretically, it would be possible to unpack system/user provided lapack library and recreate it locally without xerbla.o. Then the pythonxerbla should be always effective. However, this approach requires more work (within numpy.distutils) so that I recommend postponing the issue to 1.1.
atmention:stefanv wrote on 2008-04-09
I'd like to see the fix -- that was what I was working on this afternoon when time ran out. Could we rename pythonxerbla to python_xerbla for readability, please?
atmention:pearu wrote on 2008-04-09
No probelem with renaming.
Here follows a "fix" that should be inserted to linalg/setup.py file:
config.add_library('pyxerbla', sources=['python_xerbla.c']) lapack_lib['libraries'].append('pyxerbla') # one can also try .insert(0, 'pyxerbla')
I have tested it and it does not work if xerbla is already included in the lapack library. With gnu compiler it does have no effect and with MSVC, the linker fails because of multiple definitions of the same symbol.
I sincerily hope that you will be more succesful.
Otherwise, the fix of the issue means that lapack libraries need to be changed. This is no probelm if users build their own lapack library and then we can give detailed instructions for how to do it. But the problem will be with most users who use system wide lapack libraries.
atmention:pearu wrote on 2008-04-09
Sorry for bad formatting. Here's a fix:
config.add_library('pyxerbla', sources=['python_xerbla.c'])
lapack_lib['libraries'].append('pyxerbla')
# one can also try .insert(0, 'pyxerbla')
Milestone changed to 1.2.0
by atmention:charris on 2008-05-20
atmention:cournape wrote on 2008-08-23
This is not trivial: every blas/lapack is different in that respect, and rerouting xerbla call to a custom xerbla is platform / compiler dependant. R seems to have managed doing it, though.
Milestone changed to Unscheduled
by atmention:cournape on 2008-08-23
_Original ticket http://projects.scipy.org/numpy/ticket/673 on 2008-02-28 by trac user ZbyszekSzmek, assigned to unknown.
Function xerbla_ is called when an error (e.g. improper argument) is detected in functions converted to C from Fortran. Citing the manpage for xerbla from the lapack3 library:
XERBLA is an error handler for the LAPACK routines. It is called by an LAPACK routine if an input parameter has an invalid value. A message is printed and execution stops.
Installers may consider modifying the STOP statement in order to call system-specific exception-handling facilities.
I believe that it should indeed be customized for lapack_lite in numpy, because a. it tries to print a message using Fortran I/O, which doesn't always work b. calls s_stop, which simply exits the program returning 0
The Python interface validates all arguments, so that the error-handling code in functions converted from Fortran is not called, but in case it happens, an exception should be thrown.
An example:
On suse 10.3 (64bits) with python-numpy-1.0.4-0.pm.2 running such a program gives no output (Fortran I/O doesn't work properly?) and returns 0. On debian with python-numpy-10.0.3-1 it says:
and returns 0.
With the attached patch, python returns 1 after printing:
Of course all this is caused by a small bug in the python wrapper for dsegv.