Re: [boost] [Stacktrace] review

Subject: Re: [boost] [Stacktrace] review
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2016-12-16 04:37:29

On 12/16/16 02:45, Gavin Lambert wrote:
> On 16/12/2016 12:11, Andrey Semashev wrote:
>> The config macro to disable the stacktrace doesn't satisfy me. First,
>> because it is a way to opt out whereas I believe such a feature should
>> be an opt in as it is expensive. Second, because it doesn't work with
>> compiled binaries (e.g. distributed in package distros and Boost
>> installers). Third, I suspect this feature could be useful in a subset
>> of source code, e.g. a particular set of function calls or a scope,
>> while not so useful in other places of the application. For instance,
>> one might want to temporarily enable it to debug a particular place of
>> code without affecting the rest of the program. For that the feature
>> should be configurable in runtime.
>
> I'm curious whether your answer would change if your first two
> objections were invalid, ie. if it were not expensive and if it could be
> used for optimised and stripped binaries.

If obtaining the backtrace was cheap and of constant complexity, that 
would certainly be less of a problem. The source file location is a 
great example of that: it is cheap to obtain and transport in the 
exception, yet it provides one with a lot of information. But with 
stacktraces somehow I don't believe this is the case (wrt. the "cheap" 
part anyway).

Regarding the optimized and stripped binaries, I was actually talking 
about a different thing, I think. For instance, if BOOST_THROW_EXCEPTION 
attaches a stacktrace by default then Boost.Log library binaries 
distributed in my favorite Linux packages also do that for all 
exceptions the library throws. There is no way the user can disable that 
without recompiling the library.

But you touched another interesing subject: does the library have the 
capability of loading debug symbols to interpret the backtrace? Because 
if it doesn't then the attached stacktraces will be nearly useless for 
stripped binaries (which they all are when distributed in packages).

> (Regarding that latter point, that's what both Nat and I [in the
> pre-review] were talking about as a feature request, that the raw trace
> could be serialised and decoded later on a separate machine with access
> to the corresponding symbol files.  This practice is not uncommon in
> Windows with minidumps and pdb files.)

I think, with load address randomization, the stacktrace alone is not 
enough for that. You'd need a core dump of the process to interpret the 
backtrace.