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

Subject: Re: [boost] [Stacktrace] review, please stop discussing non-Stacktrace issues
From: Jarrad Waterloo (jwaterloo_at_[hidden])
Date: 2016-12-20 09:20:04

Think stack trace of release builds where the debug symbols have been stripped out. This is common and the default in the Microsoft world. It allows for the smallest, fastest and more secure execution while at the same time allowing for access to the stacktrace. It is accomplished by storing the debug symbols outside of the artifact, in a PDB file. A stack trace is no longer an collection of strings but rather a collection of relative virtual addresses. This information as well as artifact load address can be used with the PDB to reconstruct that stack trace. Microsoft have symbol servers which not only contain the artifact, dll or exe, but also the PDB file. PDB file can vary in size to ones that are small that provide method and line numbers to verbose that holds a lot more debug information. Since PE, portable executable, file format is mostly standard between Windows and Linux environments couldn't Linux support this functionality via using dwarf debug symbols while Microsoft uses PDB.

gcc: -gdwarf

...

All that having been said, I do believe stacktrace should be included in its present form. I just wish the author would acknowledge this use case that is the value of stack traces for release builds and is open to future revisions towards it. I also hope the community doesn't dismiss this library because it doesn't do everything but would look at it as a valuable first step. Okay Okay 10 steps.

________________________________
From: Boost <boost-bounces_at_[hidden]> on behalf of Vladimir Batov <Vladimir.Batov_at_[hidden]>
Sent: Monday, December 19, 2016 6:42:11 PM
To: boost_at_[hidden]
Subject: Re: [boost] [Stacktrace] review, please stop discussing non-Stacktrace issues

On 12/20/2016 09:11 AM, Niall Douglas wrote:
> ... Stacktrace should be able to serialise the stacktrace of an
> about to be terminated process to disc in an async-safe way in a
> format which other tooling such as addr2line or llvm-symbolizer can
> consume in combination with the debug symbols to produce an accurate
> source and line number stacktrace. Stacktrace does not need to parse
> the stacktrace in an async-safe way.

The need to have and to use an additional tool to actually see the stack
seems like a considerable complication. To me personally printing out
the stack-trace to the log was a quick and light-weight (but often
sufficient) clue where to start my investigation. How is the suggested
procedure better compared to the established on Linux -- retrieve the
core of the failed app, run it with gdb, look at the debug symbols,
stack-trace, etc.? I suspect a similar/same mechanism to already exist
on Windows as well, right?

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost