Catching floating point errors from linked C code

[John Pye]

Hi all

I have some C code that is giving me some 'nan' values in some
calculations. The C code is wrapped using SWIG to give me a Python
module that I am then exercising through a unittest suite.

It seems that I should expect the C code to throw floating point
exceptions (SIGFPE) and either the whole thing to abort, or for Python
to catch the errors and report them. Instead I'm getting neither. I
want to be able to track down the exact location of problems in my C
code.

Is there something that Python does to turn on/off the catching of
divide-by-zero errors, eg by manipulating <signal.hsign al handlers
and/or <fenv.hsettings ?

Cheers
JP

[John Nagle]

John Pye wrote:

Hi all

I have some C code that is giving me some 'nan' values in some
calculations. The C code is wrapped using SWIG to give me a Python
module that I am then exercising through a unittest suite.

It seems that I should expect the C code to throw floating point
exceptions (SIGFPE) and either the whole thing to abort, or for Python
to catch the errors and report them. Instead I'm getting neither. I
want to be able to track down the exact location of problems in my C
code.

Is there something that Python does to turn on/off the catching of
divide-by-zero errors, eg by manipulating <signal.hsign al handlers
and/or <fenv.hsettings ?

What platform are you on?

Python is probably running with floating point exceptions disabled,
but you can enable them in your C code, and restoring the floating
point mode when you leave, if you want. This is probably
only worth doing under a debugger, because otherwise you just end
up with an aborted instance of Python.

John Nagle

[John Pye]

Hi John,

On Jan 25, 3:43 pm, John Nagle <n...@animats.c omwrote:

Python is probably running with floating point exceptions disabled,
but you can enable them in your C code, and restoring the floating
point mode when you leave, if you want. This is probably
only worth doing under a debugger, because otherwise you just end
up with an aborted instance of Python.

So as far as you know, Python doesn't switch stuff like
feenableexcept( FE_EXCEPT_ALL)? Does Python use the <signal.h>
internally, or are all its FPEs detected by explicit checks beforehand?

If writing a python module with SWIG, and the module uses Python
callbacks, do I need to restore the signal handlers before running the
callback, or python do that itself?

(These might be questions better asked on the SWIG list I guess)

Cheers
JP

[John Nagle]

John Pye wrote:

Hi John,

On Jan 25, 3:43 pm, John Nagle <n...@animats.c omwrote:

>>Python is probably running with floating point exceptions disabled,
but you can enable them in your C code, and restoring the floating
point mode when you leave, if you want. This is probably
only worth doing under a debugger, because otherwise you just end
up with an aborted instance of Python.

So as far as you know, Python doesn't switch stuff like
feenableexcept( FE_EXCEPT_ALL)? Does Python use the <signal.h>
internally, or are all its FPEs detected by explicit checks beforehand?

I have no idea what state Python leaves the FPU in, but whatever
the state is, you can read it, set your own state, and restore
the previous state before returning to Python.

The last time I had to do this, I used

unsigned int oldstate = // make almost all FPU errors fatal
_controlfp ((~_EM_INVALID) & _CW_DEFAULT, _MCW_EM);
...
_controlfp(olds tate); // restore old state

on Windows 2000.
John Nagle

[John Pye]

Hi John

I think you're right, and I need to place FPE 'brackets' around my
code.

The thing that was confusing me was that python has division by zero
exceptions (for which I assumed fenv.h was being used), but when from
python I reach down into my SWIG code and do a 1/0, no SIGFPE is
thrown.

I will experiment with the _controlfp stuff (and linux equivs) and see
how it goes. Thanks for your help.

Cheers
JP
On Jan 25, 5:12 pm, John Nagle <n...@animats.c omwrote:

John Pye wrote:

Hi John,

On Jan 25, 3:43 pm, John Nagle <n...@animats.c omwrote:

>Python is probably running with floating point exceptions disabled,
but you can enable them in your C code, and restoring the floating
point mode when you leave, if you want. This is probably
only worth doing under a debugger, because otherwise you just end
up with an aborted instance of Python.

So as far as you know, Python doesn't switch stuff like
feenableexcept( FE_EXCEPT_ALL)? Does Python use the <signal.h>
internally, or are all its FPEs detected by explicit checks beforehand? I have no idea what state Python leaves the FPU in, but whatever

the state is, you can read it, set your own state, and restore
the previous state before returning to Python.

The last time I had to do this, I used

unsigned int oldstate = // make almost all FPU errors fatal
_controlfp ((~_EM_INVALID) & _CW_DEFAULT, _MCW_EM);
...
_controlfp(olds tate); // restore old state

on Windows 2000.

John Nagle