Boost logo

Boost :

Subject: Re: [boost] [Stacktrace] review, please stop discussing non-Stacktrace issues
From: Antony Polukhin (antoshkka_at_[hidden])
Date: 2016-12-18 17:26:30

2016-12-18 21:37 GMT+03:00 Andrey Semashev <andrey.semashev_at_[hidden]>:
> On 12/18/16 20:15, Antony Polukhin wrote:
>> 2016-12-18 0:29 GMT+03:00 Andrey Semashev <andrey.semashev_at_[hidden]>:
>>> On Sat, Dec 17, 2016 at 9:17 PM, Niall Douglas
>>> <s_sourceforge_at_[hidden]> wrote:
>>>> Specifically:
>>>> 1. Should Stacktrace be async safe so it can be used to print a
>>>> stacktrace from a signal/exception handler?
>>> That depends on whether any backend supports decoding the stacktrace
>>> in signal handlers. Note that if we also want to load debug symbols
>>> from a separate file while doing this, the task seems to become
>>> impossible.
>> Spawning a new subprocess in signal handler (or at the beginning of
>> the program) would be OK for you? If I'll came up with an
>> async_safe_print(stacktrace()); function that may fix the broken
>> example in docs, provide much more motivation for having non
>> allocating stacktrace class.
> If that is only possible by forking a process then I'm not sure that
> accomplishes much. I mean, if there is a non-signal-safe formatting function
> for stacktraces, there's no problem to call `fork()` yourself in the signal
> handler, use that formatting function in the child process, and pipe its
> result back to the main process. I guess, a helper function that does this
> would be useful, just make sure to explicitly document that it forks. Also,
> the non-forking formatting implementation is still needed for all cases
> other than signal handlers.

It's not that simple. After a fork() you are still in the
async-signal-processing mode. You have to call one of the exec*
functions to safely print the backtrace.

Windows has no fork(). Looks like the only way to do that safely on
Windows, is to create a process before the signal, make a pipe and
wait for data on a pipe. As soon as the signal appears - dump data
into the pipe and die. The child process have to output the content...
it seems to me that such out-of-the-box functionality won't make all
the users happy. They would definitely want to tune multiple things
that I'm failing to predict.

Best regards,
Antony Polukhin

Boost list run by bdawes at, gregod at, cpdaniel at, john at