floating point exception (SIGFPE weirdness)

[Andrew Straw]

I'm running into trouble when calling a 3rd party library (the Intel IPP
library to do some fast math on a P4 processor). This is on debian
linux 2.6.7 using python 2.3.4.

I've been using Pyrex to wrap my calls to this C library into an
extension module, and a certain function call within my extension module
(to the C function ippiAddWeighted_8u32f_C1IR) will terminate my Python
program when called for the 2nd time, with the line "Floating point
exception" mysteriously appearing on the console. (Mysterious in part
because I can't redirect these words with piping stdout or stderr.) I
should note that this function calls not only the normal Pentium
floating-point machinery, but should also call the SSE and SSE2
instruction sets.

A few clues:

1) A trivial C program which makes the same function call repeatedly
with the same data is not terminated.

2) Running the python executable under gdb causes the program to
continue running without terminating.

3) The behavior (termination) is not changed after rebuilding Python
from source, compiling with --with-fpectl and building the fpectl
module, calling fpectl.turnoff_sigfpe().

I don't really understand what is happening, but I'd like my code to run
without terminating due to this floating point exception. My best guess
is that SIGFPE is being generated by the C function call, and Python
does not catch it so the OS terminates Python. If this is so, however,
I'm not sure why Python should be terminated and why my simple C program
is not. Furthermore, I don't understand why gdb doesn't see SIGFPE if
this is the case.

I would be very grateful if someone could tell me how to keep my program
running!

Cheers!
Andrew

[Andrew Straw]

I figured out that the culprit is in the numarray.ieeespecial module,
which my Python code imports.

The lines (taken from ieeespecial.py)

import numarray.numarrayall as _na
plus_inf = inf = _na.array(1.0)/_na.array(0.0)

are sufficient to cause the behavior in my original post. I shall
follow this up on the numpy discussion list.

Andrew Straw wrote:

I'm running into trouble when calling a 3rd party library (the Intel IPP
library to do some fast math on a P4 processor). This is on debian
linux 2.6.7 using python 2.3.4.

I've been using Pyrex to wrap my calls to this C library into an
extension module, and a certain function call within my extension module
(to the C function ippiAddWeighted_8u32f_C1IR) will terminate my Python
program when called for the 2nd time, with the line "Floating point
exception" mysteriously appearing on the console. (Mysterious in part
because I can't redirect these words with piping stdout or stderr.) I
should note that this function calls not only the normal Pentium
floating-point machinery, but should also call the SSE and SSE2
instruction sets.

A few clues:

1) A trivial C program which makes the same function call repeatedly
with the same data is not terminated.

2) Running the python executable under gdb causes the program to
continue running without terminating.

3) The behavior (termination) is not changed after rebuilding Python
from source, compiling with --with-fpectl and building the fpectl
module, calling fpectl.turnoff_sigfpe().

I don't really understand what is happening, but I'd like my code to run
without terminating due to this floating point exception. My best guess
is that SIGFPE is being generated by the C function call, and Python
does not catch it so the OS terminates Python. If this is so, however,
I'm not sure why Python should be terminated and why my simple C program
is not. Furthermore, I don't understand why gdb doesn't see SIGFPE if
this is the case.

I would be very grateful if someone could tell me how to keep my program
running!

Cheers!
Andrew