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