[Numpy-discussion] Unhandled floating point exception running test in numpy-1.0.3 and svn 3875
Thu Jun 28 15:56:40 CDT 2007
there was a bug that made it into debian sarge whereby a SIGFPE wasn't
trapped in the appropriate place and ended up causing problems similar
to what you describe. the difficulty in debugging is that you're after
whatever triggers the FPE in the first place (or the bug that lets it go
untrapped), but you only get notified when the kernel kills your program
for not trapping it. I wrote a little page about the Debian sarge issue:
John Ollinger wrote:
> 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>"
> Numpy-discussion mailing list
More information about the Numpy-discussion