Re: [boost] Review Manager needed for stacktrace library

Subject: Re: [boost] Review Manager needed for stacktrace library
From: Antony Polukhin (antoshkka_at_[hidden])
Date: 2016-10-26 02:14:31

2016-10-26 1:13 GMT+03:00 Gavin Lambert <gavinl_at_[hidden]>:
> 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.

Already done. + stack capturing is noexcept. Thou not all the backends
have great performance. I'll improve the docs by highlighting the
performance differences for backends.

> 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).)

Already done. + copy constructor is noexcept.

> 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).

Already done for function names, source and line info will hopefully come soon.

> 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.

That's interesting! I'll make it possible to have that functionality
by adding an get_address() function to the frame class. I'll try to
implement that and provide an example in docs soon.

Great thanks!

> (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.)

Not sure that the library is meant for that: such functionality
requires additional care, permissions and probably special compiler
support.

-- 
Best regards,
Antony Polukhin