[Numpy-discussion] Unhandled floating point exception running test in numpy-1.0.3 and svn 3875

[John Ollinger]

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?
> 
> -rex
> 


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
http://www.ibm.com/developerworks/eserver/library/es-033104.html 
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. 

John

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>"