Strange segementation fault
Dear cctbx-developers, I recently started to use the cctbx. Some days before i may have found a bug. Description: When I import from the cctbx and perform a division through zero (with array objects from numpy) something segfaults. I've appended a script that demonstrates this behaviour. Maybe it's just a problem with my specific system (I did not observe this behaviour on windows). I've compiled the cctbx from the unix sources with the build tag 2008_09_13_0905 on a debian testing system: Python 2.5.4, gcc 4.3.3, libboost.python1.37.0 Do you need information on other libraries too? Can anybody reproduce this or has an idea what could be wrong? Maybe someone can give me a hint how I could try to debug this? Thanks Armin -----------------8<--------------------8<------------ import numpy as np a = np.array([[1,2,3],[4,5,6]]) b = np.zeros(a.shape) b[[0,0,1],[1,2,0]] = 1 c = a/b print 'before import x/0 is not a problem' print c import cctbx from cctbx import xray, crystal, miller, sgtbx, uctbx from cctbx_array_family_flex_ext import miller_index import scitbx_array_family_flex_ext from iotbx.shelx import from_ins lo = b!= 0 c = np.ones(a.shape)*np.inf c_div = a[lo]/b[lo] c[lo] = c_div print 'after import workaround' print c print 'after import x/0 ==> segfault' print a/b
Hi Armin,
When I import from the cctbx and perform a division through zero (with array objects from numpy) something segfaults.
During the first import of any cctbx module, some code is run to switch on the trapping of floating point exceptions. Thus after that import, divsion-by-zero, NaN-production and overflows result in a stacktrace indeed, which is usually not the default. You should see a message telling you about one way to suppress that behaviour (after the stacktrace). You can indeed set any of the following environment variable: BOOST_ADAPTBX_FE_OVERFLOW_DEFAULT, BOOST_ADAPTBX_FE_INVALID_DEFAULT, BOOST_ADAPTBX_FE_DIVBYZERO_DEFAULT, BOOST_ADAPTBX_FPE_DEFAULT. They respectively revert to the default behaviour of your platform for respectively overflows, NaN, division by zero and all of those three. There is a programmatic way to suppress trapping too. from boost.python import floating_point_exceptions # Then any combination of the following floating_point_exceptions.division_by_zero_trapped = False floating_point_exceptions.invalid_trapped = False floating_point_exceptions.overflow_trapped = False
I did not observe this behaviour on windows
We have not installed those traps on Windows indeed. Only on Linux and MacOS X. Luc Bourhis Computer Scientist Chemical Crystallography Laboratory University of Durham, UK
I've compiled the cctbx from the unix sources with the build tag
2008_09_13_0905 on a debian testing system:
Luc's reply assumes that you have a more recent cctbx version. This improved message only appears in versions after 2008-11-24: Floating-point error (Python and libc call stacks above) This crash may be due to a problem in any imported Python module, including modules which are not part of the cctbx project. To disable the traps leading to this message, define these environment variables (e.g. assign the value 1): BOOST_ADAPTBX_FPE_DEFAULT BOOST_ADAPTBX_SIGNALS_DEFAULT This will NOT solve the problem, just mask it, but may allow you to proceed in case it is not critical. Luc's instructions for customizing the floating-point traps only applies for versions after 2009-01-29. But setting the environment variables should also work with your version, I think. If you want to upgrade, use cctbx version 2009_07_21_2348 from here: http://cci.lbl.gov/cctbx_build/all.html Ralf
Ralf W. Grosse-Kunstleve schrieb:
I've compiled the cctbx from the unix sources with the build tag
2008_09_13_0905 on a debian testing system:
Luc's reply assumes that you have a more recent cctbx version. This improved message only appears in versions after 2008-11-24:
Floating-point error (Python and libc call stacks above) This crash may be due to a problem in any imported Python module, including modules which are not part of the cctbx project. To disable the traps leading to this message, define these environment variables (e.g. assign the value 1): BOOST_ADAPTBX_FPE_DEFAULT BOOST_ADAPTBX_SIGNALS_DEFAULT This will NOT solve the problem, just mask it, but may allow you to proceed in case it is not critical.
Luc's instructions for customizing the floating-point traps only applies for versions after 2009-01-29. Thanks a lot to both of you. I had no time to try it until yet, but I will do this soon.
Armin
participants (3)
-
Armin Moser -
Luc Bourhis -
Ralf W. Grosse-Kunstleve