General
cancel
Showing results for 
Search instead for 
Did you mean: 

U_STACK_TRACE in signal handler recurses deeply if signal handler in a different object file

Alexey Roytman
Frequent Advisor

U_STACK_TRACE in signal handler recurses deeply if signal handler in a different object file

A common practice of handling crash signals (SIGBUS/SIGSEGV/etc) is to use U_STACK_TRACE in signal handler.

Everything is fine until we separate the code that actually causes the crash, and the signal handler that calls U_STACK_TRACE, to separate source code files, compile them separately and then link the object files.

Then, the call to U_STACK_TRACE may recurse deeply and even crash again with SIGILL, for example. Still, the crash that happens in the same object file that has signal handler, works as designed.

I've attached source files, makefile, system versioning information.

Maybe, someone can help me.
2 REPLIES
Dennis Handly
Acclaimed Contributor

Re: U_STACK_TRACE in signal handler recurses deeply if signal handler in a different object file

The problem with "s" and "r" occurs because the Unwindlib knows nothing about sigaltstack(2) and thinks the framesize is larger than SP and then calls U_PRINT_ERR and gets into a recursive loop. If there is a difference because of the different object file, it's more likely due to the fact there is an extra frame.
Please contact the Response Center and file a bug report.

Probably the only reason "R" works is because it doesn't trace all of the recursive crash frames?

On IPF, "R" and "r" fail because sigaltstack(2) doesn't seem to handle RSE stack overflows. I see no evidence of it getting to the signal handler.
Dennis Handly
Acclaimed Contributor

Re: U_STACK_TRACE in signal handler recurses deeply if signal handler in a different object file

>because the Unwindlib knows nothing about sigaltstack(2)

This was fixed last year.