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

Subject: Re: [boost] [Stacktrace] review, please stop discussing non-Stacktrace issues
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2016-12-18 08:56:00

On 18 Dec 2016 at 0:29, Andrey Semashev wrote:

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

If you preload the symbols and prebind the COM functions you'll use 
in the async unsafe handler, I've found decoding the stacktrace to be 
reliable in the past on Windows.

On POSIX launching a subprocess and parsing its output is async safe. 
I have to admit I've always launched addr2line or llvm-symbolizer. 
It's nasty and slow but it works.

> > 2. Is its lack of thread safety on Windows a problem?
> 
> Yes, I think that is a serious problem. Though I'm not sure if
> Boost.Stacktrace can do something about it, except to introduce a
> global lock (sigh).

Thankfully as I just recently discovered Stacktrace is using Dbgeng 
not Dbghelp. That means it's threadsafe (yay!).

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/