Linked by Eugenia Loli-Queru on Wed 13th Dec 2006 04:33 UTC, submitted by IdaAshley
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.
Thread beginning with comment 191846
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
Recent Original Stories
Recent Comments
Headlines
Random Comments
Random Stories
Random OS Link
Member since:
2006-01-17
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.