Re: [boost] [stacktrace] Two days remaining before review ends

Subject: Re: [boost] [stacktrace] Two days remaining before review ends
From: mbartosik (mbartosik_at_[hidden])
Date: 2017-04-10 22:41:31

*Address space layout randomization*
How does boost stacktrace cope with ASLR (address space layout
randomization)?
This is where the load address of a module is randomized by the operating
system loader to at an unpredictable address to help protect from viruses
using techniques like buffer overrun attacks.
The use case that I am concerned about is calling
boost::stacktrace::safe_dump_to and later resolving the function names with
boost::stacktrace::stacktrace::from_dump. Without the module load addresses
(and the module paths) I do not see how the frame symbols can be resolved. I
think that it is possible to address this by a future enhancement like
having a process modules class possibly with a similar interface to boost
stacktrace, and then to boost::stacktrace::stacktrace::from_dump might be
extended take an additional argument of a 'process modules' class which has
similarly been reconstructed.

Having said this since I understand your expectation is possibly not to use
in production (as build flags need to be set) then this may not be so
serious, for use in production I would consider it a serious problem. I
would like to be able to use this in production with both ASLR enabled and
with code that may have optimizations on that make the stack harder to trace
(including third party code for which I have no control of build settings).

*Aggressiveness in walking stack:*
It is inevitable that developers will want to use this in production code
likely a release build with the optimizer on. Thus I was hoping for an
option to use more aggressive algorithms (which could not be used within
signal handlers). Using only the least aggressive method will significantly
limit the usefulness -- but probably better to have a 1.0 version that
requires compiler options than nothing maybe a 2.0 version will be able to
support more aggressive algorithms for walking the stack.

*Use on non-current threads:*
To collect a stack in a different thread I know is possible and portably
because I've seen it done on most platforms (this is what a debugger does
when it dumps the stack of a target process). This is why the ReadMemory
argument in Microsoft's StackWalk64 API is provided. All that is required is
that we know that the thread being walked is paused. The idea being that if
a deadlock is detected stacks for multiple threads can be logged but without
of course requiring the deadlocked threads to do the walking. Potentially if
stack tracing of other processes where supported it could be used to write
watch dog processes, and even generate a stack trace for a stack overflow
error (which is notoriously difficult to code for).

*Out of the box caching:*
Without adding extra classes the best I have is to add global map of address
to string/symbol info (possibly with pruning of least used elements) for use
by frame::name etc.
The concern I have is thus:
  Let's say to_string for a single frame takes ~ 0.1 seconds.
  Let's say our stack trace is 10 frames deep.
  The to_string for the entire stack trace takes ~ 1 second.
If a developer adds logging for some apparently rare exception in the hope
of diagnosing a problem, but in production under some circumstance that
exception occurs maybe once in 2 seconds, then the code will spend half it's
wall time just logging stack traces. Basically it is too easy to
accidentally grind some code to a halt by adding a diagnostic - which I
think it just too dangerous.

So my only advice / idea is to provide a global thread safe cache for
symbolic information that is configurable either by functions in the
namespace boost::stacktrace (preferred) or by build options.

*Control over what frame::to_string / frame::name do *
What I was thinking was whether there should be some user control over how
the name for the frame is reported e.g.
bar(int), void bar(int), void namespace::bar(int), bar(), __stdcall void
bar(int), ?bar@@YAH_at_Z
This is not something that I consider particularly important, it might be
food for thought for you.

I know that this is quite a bit of comment and that the official review
period is over (I was getting married plus honey moon while the review was
on). I do think this is an great addition to have in boost. 
- Mark

--
View this message in context: http://boost.2283326.n4.nabble.com/stacktrace-Two-days-remaining-before-review-ends-tp4692916p4693619.html
Sent from the Boost - Dev mailing list archive at Nabble.com.