Re: [boost] Review Manager needed for stacktrace library

Subject: Re: [boost] Review Manager needed for stacktrace library
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2016-10-25 18:13:26

On 26/10/2016 08:14, Antony Polukhin wrote:
>> Could it be move-only?
>
> Yes, but that will make the situation worse :(
> Class stacktrace does not hold actual `frame` instances, it holds a
> raw pointers or some high-level stuff that has different size
> depending on the backtrace backend. If I make the `frame` class
> copyable, it will either
> * break the ability to disable stacktraces without recompilation; will
> not allow to change backends transparently
> * lead to nonintuitive situation, that `frame` is just a reference to
> actual frame data that is kept inside stcktrace class. So a copy of
> `frame` becomes invalid after the stacktrace destruction.

Not sure if this helps or hinders, but these are the things I would 
consider to be most important in a stacktrace library:

1. Capturing the current state/trace should be as fast as possible.

2. This captured context should be able to be copied/moved into an
exception or into a container and passed to a different thread for later 
use.  (It is reasonable to only be able to do so for the context as a 
whole, not individual frames, although it's also useful to be able to 
"trim" the captured context before storing it (eg. omit the first few 
frames which are inside stack-trace-capturing methods rather than places 
of interest).)

3. In this secondary location it should be possible to symbolise the 
stack trace (ie. turn raw addresses into function/source/line info). 
And in particular this should be done only on such request, not at the 
original point of capture (to make that faster).

4. It would be useful, though not essential, to have a serialisation 
format such that the context from #1 can be saved to a file and a 
separate utility on a separate machine can be used to do #3 (similar to 
addr2line, but better).  It's reasonable to require that the original 
binaries and symbol files are available to perform the symbol decoding, 
and it's expected that the serialisation format would have to include 
not just the trace addresses but also the module load addresses, since 
they might have loaded in different locations than their binary headers 
specify, especially on machines with ASLR enabled.

(re: #1, I'm thinking in part of the ETfW sampling, which is able to 
capture stack traces from all threads every millisecond and every 
context switch, among other events, without noticeably slowing down even 
a high-performance application.  Comes in surprisingly handy at times to 
have capturing that fast, even when doing it more ad hoc rather than 
sampling.)