I'm doing a debug on a program which report:

Thread 1 "test.out" received signal SIGSEGV, Segmentation fault.

I then gdbed the program and found out that the program jump into a SignalHandler function right after a call instruction call 0x401950.

I tested the call destination rax, rdi and rsi (Input of the call). However nothing strange found.

I haven't meet this situation before, I guess there is an soft interrupt created due to some of the exemption, which then scheduled after the instruction. So the actual problem may occur earlier.

Now I need to find out where rises the exemption, so that I could fix it. But I do not have any clue on how.

Therefore I came to ask if anyone could help me on that.

One big sorry for not showing the code, since it is company asset.....

Thanks for anyone who helps!!!

CodePudding user response：

I then gdbed the program and found out that the program jump into a SignalHandler function right after a call instruction call 0x401950.

You didn't say which processor and OS you are using. Guessing Linux and x86_64, you have a stack overflow.

The CALL instruction pushes return address onto the stack, and this operation will generate SIGSEGV if your stack is exhausted.

You can confirm this guess by using (gdb) where (which is likely to show very deep recursion, though other reasons for stack exhaustion are also possible), and by looking at the value of RSP (which should be just below page boundary).

Depending on how the stack size is set up, using ulimit -s unlimited before invoking the program may work around this crash (though you really ought to fix the root cause by some other mechanism).