trap a SIGFPE

[Jack_S_]

Hi all,

I'm running a multiple file Fortran 90 code using IDB, and at some point I get  :

**Program received signal SIGFPE**

The problem is that the IDB throw me to the Assembly page and not to the line when it happend. I'm not familiar with assembly

I'm using the ''traceback'' option for compiling those files. Specifically :

**ifort -g -O3 -openmp -openmp-report -msse4.2 -fpconstant -fp-model strict -fpe0 -traceback -ftrapuv -convert big_endian**

Can anybody please advise on how to get the specific line of the source code ?

Thank you all,

Jack.

[Rob_Mueller-Albrecht]

Hi Jack,

your program raises an arithmetic exception. Most likely a division by zero. Once the code runs into the exception hander the callstack most likely gets lost and hence the debugger stops you in the exception handler (which is in signal.c in the Linux kernel source).

If you have control over you Linx sources you could add a break instruction into the SIGFPE signal hander begore it gets actually executed. Then you should still have callstack backtrace.

If you only have user space access to your code, there is a slightly cumbersome method that involves adding library functions that modify the signal handling for your specific application:

Integer division-by-zero errors can be trapped and identified by re-implementing the appropriate C library helper functions. The default behavior when division by zero occurs is that when the signal function is used, or __rt_raise() or __aeabi_idiv0() are re-implemented, __aeabi_idiv0() is called. Otherwise, the division function returns zero. __aeabi_idiv0() raises SIGFPE with an additional argument, DIVBYZERO.

Hope this helps.

Thanks, Rob

[Jack_S_]

Hi Rob,

Thanks for your replay.

I have control over my Linux sources. However, I'm not sure how to add a break instruction into the SIGFPE signal handler. I understand according to your explanation that its in signal.c in the Linux kernel source - could you please elaborate in how this is being done, so every SIGFPE that I have I could see the specific source line ?

Thanks in advance,

Jack.

[Rob_Mueller-Albrecht]

Hi Jack,

I think I need to correct my previous statement. I had an additional conversation with one of my colleagues who focuses more on uer space debug with GDB (I am more of a system level debug guy).

There are additional exception handlers in user space object code. Especially as you are using -traceback, additional code is being generated that captures tehse types of exceptins early on. Hence you will probably end up in compiler generated excpetion capture code instead of t he system level exception handler I pointed you to before. 

What happens if you compile without compiler checks: -traceback, -check?

Does the code run without problems then?

GDB does not play nicely with these compiler checks and thus this could be what you are observing instead of a more serious problem.

Please send us the callstack and assembly of the relevant code as a private attachment if this does not help.

Thanks, Rob

P.S. The way to implement a breakpoint in a source file is simple to add __asm__("int3");

[Jack_S_]

Hi Rob,

Sorry for the slow replay.

I have checked it as you suggested and it keeps throw me to the assembly interface in the IDB without giving any information about the source line.

I have sent you a private message with the assembly and call stack. Kindly waiting for your advice.

Thank you,

Jack.