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.