2016-12-22 23:06 GMT+03:00 Vladimir Batov
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?
Actually, I think that Stacktrace must perfectly fit your needs. Here's how I understand your situation: you've got a big application, that runs 24/7 and is automatically restarted after a crash; a support team of non-developers that monitor it and send logs. It would be a disaster if your application hangs, so you need an async-signal-safe code. Sending corefiles is hard - application is big and support team is not trained to do that. Log files with a stacktrace would significantly help you in debugging. Here's how you can use the stacktrace: dump_stacktrace("/staktrace.txt"); // in signal handler, async signal safe ... // in main() if (filesystem::exists("/staktrace.txt")) { std::ifstream ifs("/staktrace.txt"); } -- Best regards, Antony Polukhin