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.