I'm trying to debug a SIGFPE
signal that is raised inside a library that I don't have it's source code. I'm using gdb and the asm layout to see what is going on.
These are the instructions before the exception:
0xcd3fffa <_ZN8name_space11ClassName1MethodNameEdddd+830> fstpl -0x68(%ebp)
B+ 0xcd3fffd <_ZN8name_space11ClassName1MethodNameEdddd+833> fldl -0x58(%ebp)
0xcd40000 <_ZN8name_space11ClassName1MethodNameEdddd+836> fstpl 0x4(%esp)
0xcd40004 <_ZN8name_space11ClassName1MethodNameEdddd+840> mov 0x8(%ebp),%eax
0xcd40007 <_ZN8name_space11ClassName1MethodNameEdddd+843> mov %eax,(%esp)
>0xcd4000a <_ZN8name_space11ClassName1MethodNameEdddd+846> call 0xcd408c0 <_ZN8name_space11ClassName1AnotherMethodNameEd>
0xcd4000f <_ZN8name_space11ClassName1MethodNameEdddd+851> mov 0x8(%ebp),%eax
When I type ni
to go from the instruction at 0xcd4000a
to the one at 0xcd4000f
I get the following error
Program received signal SIGFPE, Arithmetic exception.
0x0cd408e8 in name_space::ClassName::AnotherMethodName(double) () at /Path/to/ClassName.h:69
I am not familiar with assembly but I was expecting the instrcution pointer to be 0xcd408c0
where the instructions for AnotherMethodName
start. But the instruction pointer has jumped to 0xcd408e8
address. Which is still inside AnotherMethodName()
method.
0xcd408e4 <_ZN8name_space11ClassName1AnotherMethodNameEd+36> fldz
0xcd408e6 <_ZN8name_space11ClassName1AnotherMethodNameEd+38> fdivrp %st,%st(1)
>0xcd408e8 <_ZN8name_space11ClassName1AnotherMethodNameEd+40> fldz
0xcd408ea <_ZN8name_space11ClassName1AnotherMethodNameEd+42> fucomip %st(1),%st
After the instruction at 0xcd408e8
it jumps to my exception handler.
I have searched a lot to even get to this point. But at the moment I have no clue how I should continue.
I have also checked the floating point registers and they don't seem to contain any weird values.
What is raising this exception?
Cannot be fldz
since it just sets a register to 0
The exception occurred at fdivrp %st,%st(1)
You said you checked "wierd" values. But above must be a division by zero. Did you check st for zero too? must be zero. No weird, just zero.
FDIVRP ST(i), ST(0) Divide ST(0) by ST(i), store result in ST(i), and pop the register stack
Edit: not sure of what's happening there. Check the parameters you're calling your third party software with. You may have passed some zero value for say, number of items, maybe because of uninitialized variables which the library does not like. (sorry for all the guesswork!)
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.