Re: [boost] [Stacktrace] review, please stop discussing non-Stacktrace issues

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