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

Subject: Re: [boost] Stacktrace review: concern, probable solution and review news
From: Vladimir Batov (Vladimir.Batov_at_[hidden])
Date: 2016-12-23 01:04:18

On 2016-12-23 09:03, Andrey Semashev wrote:
> 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.

Maybe I panicked too early. If it has to be as described above, then 
we'll probably have our users to run a script running the actual 
application plus that additional dump-decoding application to have the 
textual stack-trace as the output. GDB can do that for un-stripped 
application. If you lib can do that for a stripped app, then it'll be a 
plus.

> 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.

Even though I do not see myself wanting "all threads in the crashed 
application" I do tend to agree that it'll be hard/impossible to beat 
gdb to create crash reports. However, I readily admit I am not an expert 
in the area.

> Maybe the library should just focus on the use in general
> contexts instead of signal handlers. There's too much missing
> otherwise.

That's, in fact, how we use backtrace(), backtrace_symbols() -- when I 
check pre/post conditions and realize that things have been messed up. 
Then I log the stack-trace with some more info and exit/die. It's not a 
replacement for gdb-based core analysis. It's a part of a quick 
what-went-wrong message which is often sufficient to nail the problem 
and fix it without getting the core and analyzing it.

>>> 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.

Yes, the signal handler can be called in multiple threads. However, I 
was/am under impression that while inside a signal handler you do not 
need to serialize access to some global memory as there won't be another 
signal handler running in another thread. I might be wrong though.