On 12/22/16 23:06, Vladimir Batov wrote:
On 12/22/2016 10:21 AM, Andrey Semashev wrote:
The idea is that the stack-based allocator is used in a signal handler. The stacktrace created in that context cannot escape the signal handler and can be used e.g. to save the backtrace to a file.
I hate to sound like a broken record but every time I read "to a file" I get concerned as it does not seem to fit our deployment case. Airline scheduling and disruption management. There are people on call 24/7 to address the situations when our s/w crashes. The operators have no issues/difficulties with the logs and, in fact, they send us those automatically without asking. It is really a stretch expecting them to find, handle, copy files or to run an extra application. Probably doable but I am not convinced. So, retrieving such a file from their secured system will be a royal pain. I might have missed that but dumping the textual stack-trace to the log is still on the cards, right?
Having a decoded stacktrace as a result of signal would be ideal. But apparently that is not possible without either forking the process and decoding the stacktrace in the child, or dumping undecoded stacktrace to a file so that it can be later processed by another application. The more I think of it, the less Boost.Stacktrace seems suited for the crash handler case. It doesn't load debug symbols, it doesn't allow dumping all threads in the crashed application. Really, I can't see myself wanting to use Boost.Stacktrace instead of gdb to create crash reports. Maybe the library should just focus on the use in general contexts instead of signal handlers. There's too much missing otherwise.
The static storage fits that use case as well, although care must be taken to avoid concurrency issues. Perhaps, a thread-specific static storage would be an even better alternative.
Yes, thread_local certainly seems in order... Although I am under impression that POSIX signals are delivered to only one thread and, when that happens, the other threads are stopped. If so, then no need for thread_local... But I am admittedly hazy on handling signals in MT environment.
Generally, that depends on how you set up signal handling. But you definitely want to process crash signals in the offending thread to get its stacktrace, which means the signal handler can be called in multiple threads.