Re: [boost] Stacktrace review: concern, probable solution and review news

Subject: Re: [boost] Stacktrace review: concern, probable solution and review news
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2016-12-22 17:03:46

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.