zirias@
Developer
Background: I'm trying to add as much "robustness" as possible to my service code I use in my own daemons. For that purpose, I already have some custom "panic" function that uses longjmp(3) to get directly after the service main loop, so the most basic cleanup code is executed before exiting (and tested in isolation, this is working fine).
Now, you always want to keep your code free of bugs, but in practice, they might happen anyways, possibly causing one of the signals that by default would dump core. Thinking about how to handle these signals (e.g. SIGILL, SIGBUS, SIGSEGV, …), resuming normal execution seems quite impossible and
On stackoverflow, I found a claim that
Now, I have two questions:
Now, you always want to keep your code free of bugs, but in practice, they might happen anyways, possibly causing one of the signals that by default would dump core. Thinking about how to handle these signals (e.g. SIGILL, SIGBUS, SIGSEGV, …), resuming normal execution seems quite impossible and
longjmp() comes to mind (maybe, optionally, logging a stacktrace first with backtrace(3)). Problem here: longjmp() is not async-signal-safe.On stackoverflow, I found a claim that
longjmp() from a signal handler would be safe as long as you're not in the middle of executing another async-signal-unsafe function.Now, I have two questions:
- Is that claim true?
- Is it safe to assume these core-dumping signals will never occur inside an async-signal-unsafe library function?