[Numpy-discussion] Unhandled floating point exception running test in numpy-1.0.3 and svn 3875
ollinger at gmail.com
Thu Jun 28 16:09:32 EDT 2007
rex <rex <at> nosyntax.com> writes:
> There doesn't appear to be a problem with recent versions of the
> software. In particular, ATLAS 3.7.33 does not cause an error.
> Is there some reason for you to use such old software? (gcc 3.3.1 &
> kernel 2.4.21)? What platform are you building for?
I think have resolved this problem. First off, I building
on such an old system because the applications I write are
used at a number of labs across the campus and most of these
labs are in nontechnical departments with minimal linux support.
As a result, the usually run the version that was current
when the machine was purchased. If I want people to use my
code, I have to supply them with a tar file that contains
everything they need, including the dependencies for numpy,
scipy, wxPython, vtk and itk. I try to make a general
build on the oldest version I have access to in case I miss
something. The motherboard on my desktop died last week,
so I was forced to use the older system for a couple of weeks,
which is what prompted me to update numpy from numeric.
The floating exception is definitely not caused by the numpy
or scipy builds. The same builds run correctly on one of our
newer systems (2.6.9). I rebuilt everything on my desktop
(including gcc. The new box on my desk is now running
2.6.28 with gcc 4.1, so I had to build gcc 3.6 anyway).
The new build has the Floating point exception, but in a
different, later test (three tests after the matvec test).
Then I rebuilt a new version of gcc (3.6 rather than 3.3 and
built numpy again. The floating point exception still
occurred but this time at the cdouble test, the third from last.
The fact that the build runs find with nonoptimized lapack
libraries made me wonder about the threading support. I
found an article at
which said that SUSE 2.4.21 used a backported version of the
new threading package in version 2.6. The exceptions always
occur on complex operations, so it isn't a stretch
to assume that threads are in play when they occur.
p.s. My desktop is now running selinux, which is denying access
to the numpy shareable libries. The error message is "cannot
restore segment prot after reloc". The numpy setup script
should probably set the context for the libraries. I am going to
post this on a separate thread since other people will
probably be encountering it. For those googling this, the command
is "chcon -t texrel_shlib_t <filename>"
More information about the NumPy-Discussion