Boost logo

Boost :

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at