http://www.osnews.com/story/16709/Signals_as_a_Linux_Debugging_Tool Exploring the Future of Computing en-us Copyright 2001-2009, David Adams adam+nospam@osnews.com Tue, 10 Nov 2009 02:47:50 GMT http://www.osnews.com/images/osnews.gif http://www.osnews.com http://osnews.com/thread?191603 http://osnews.com/thread?191603 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. Wed, 13 Dec 2006 06:28:00 GMT donotreply@osnews.com (taos) Comments http://osnews.com/thread?191670 http://osnews.com/thread?191670 do i need std=c99 in order to compile the code snippets? Wed, 13 Dec 2006 12:08:00 GMT donotreply@osnews.com (netpython) Comments http://osnews.com/thread?191846 http://osnews.com/thread?191846 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. Thu, 14 Dec 2006 00:22:00 GMT donotreply@osnews.com (megacoder) Comments http://osnews.com/thread?192560 http://osnews.com/thread?192560 good info! Fri, 15 Dec 2006 10:49:00 GMT donotreply@osnews.com (deanlinkous) Comments