 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Andy
Guest
|
 Posted: Wed Sep 14, 2005 9:48 am Post subject: Signal handler in C++ |
 |
|
I am writing an error handler framework in C++ on HP-UX 11i (and
porting possibilities are ample) for an analytics product and as part
of it we need to generate stack-traces on the fly in response to any
signals which cause the program to terminate.
I am looking for designs which encapsulate signal handling well and
expose a minimalistic interface. Any pointers on this?
<-- not so relevant to this newsgroup -->
One suggestion was to fork the application and then take a core dump of
it. Are there any programmatic ways of taking core dumps of an
application with code called from within it. How feasible would this
be? What other means of generating diagnostic traces exist?
Also, is it possible or advisable to fork an application in a signal
handler.
<-- not so relevant to this newsgroup -->
Cheers,
Andy
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
 |
dayton
Guest
|
| Posted: Thu Sep 15, 2005 1:14 am Post subject: Re: Signal handler in C++ |
|
|
Andy wrote:
| Quote: | I am writing an error handler framework in C++ on HP-UX 11i (and
porting possibilities are ample) for an analytics product and as part
|
HP compilers and runtime libraries allow you to throw exceptions from
signal handlers, but a lot of runtime environments don't allow it. Your
basic problem is you're taking a non-C++ entity and trying to map it
into the C++ world. You must worry about setting up signal handlers for
every thread, and signal waiters for signals arriving from the outside
world. When you set up your signal handling, make sure to handle the
signals on the stack, rather than the alternate stack, or else C++ won't
know how to unwind it. Make your job easier by making a thread class
that handles exceptions, and deriving all your application threads from
that class. Use boost threads as your base (even though I find boost
threads very C like -- your threads class will need to account for
reaping thread resources and status even if you use boost threads).
Probably the most reliable way to deal with external signals is to use a
boost thread and wait for the signal. This actually maps well into
non-UNIX systems, because the signal waiting corresponds to console I/O
or Windows messages. You can use a single signal waiter for the entire
process.
Internal signals that come from segmentation violations, illegal
operands, look a lot like exceptions. On HP-UX and the new Sun Forte
compilers, just throw an exception from your signal handler. Windows
doesn't have signals, instead they use "structured exceptions". On
other platforms, you'll need to use some non-POSIX SysV extensions to
signal handling to establish a C++ environment from which to throw an
exception. Use the UNIX sigaction() call to set up your signal handler.
Usually the third parameter to a sigaction() call is a
setjmp()/longjmp() buffer. On arrival in your signal handler that
buffer will contain the address of the instruction after the instruction
that caused the exception. Substitute the address of a C++ function
that throws and exception for that return address. When your signal
handler returns, instead of returning to the function where the error
occurs, the program will instead throw an exception from that spot,
using the stack of the offending thread and function.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
