By focusing on the analysis of data captured using signal handlers, you can speed up the most time-consuming part of debugging: finding the bug. This article gives a background on Linux signals with examples specifically tested on PPC Linux, then goes on to show how to design your handlers to output information that lets you quickly home in on failed portions of code.
Signals as a Linux Debugging Tool
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
So many ‘smart’ programmers write their own handler for SIGSEGV, SIGILL etc. in the application, which often makes debugging much more complicated if not impossible.
My advice: if you really want to do that, then also provide a way to disable your non-default handler at run time without the need of recompiling.
BTW, better read about signal-safe and ‘reentrant functions’ (printf?) before write your handlers.
do i need std=c99 in order to compile the code snippets?
Adding signals to an application vastly complicates the entire codebase because each system call can potentially return an EINTR error code, not because of an error but because a signal got delivered during the system call. This has implications all over the application.
Still, the examples were for catastrophic signals with no recovery actions and as far as they went that’s OK.
Obtaining the sending context via siginfo is useful so that an application can vet the signal, but trying to decode the application context is probably useful only to a debugger. Instead, I’d just setrlimit(2) to enable a real core dump, abort(3), and use a proper postmortem tool such as gdb(1) which is a portable solution.
good info!