On 24 Oct 2016 at 21:05, Antony Polukhin wrote:
I do love the idea of a portable facility to capture and/or display stack traces at any desired point in a running program. Seems way overdue...
It would be even more valuable if line number and source file information were available. I recognize that you just can't get that under all circumstances -- but maybe you could document the per-platform circumstances in which that *could* be retrieved?
The idea is good and I'm definitely going to experiment with that for Windows platform and for the Linux platforms soon. But I'm afraid that it may lead to bigger backtraces that do not fit onto screen and are harder to read.
I haven't done a deep dive into Backtrace yet, I'm hoping this weekend. But the lack of iterators problem is one I'd already noticed. I was also going to propose lazy symbolisation, so only if the user specifically asks for source code file or line number is llvm-symbolizer (or the equivalent for some platform) invoked per stack frame. That implies a dependency on Boost.Process, but Boost-lite actually has a lightweight zero dependency embedded process manager which like all Boost-lite libraries is drag and drop in friendly. I was going to suggest embedding a copy of that.
If function name, source file and line number were (conditionally) available, I'd like to be able to retrieve an individual entry that has accessors returning each of those things -- instead of operator[] returning only a std::string for function name. Perhaps the source file and line number would have to be wrapped in boost::optional.
I'm writing stacktrace library as a prototype for further adoption into the C++ Standard (I've got big ambitions and groundless optimism). Additional dependency to std::optional could make the adoption harder.
It's also a pointless optimisation. Reliable symbolisation on some platforms is a very, very heavy overhead, it involves launching a whole new process, waiting for it to complete and parsing its output. A std::string for the source file name which is null until lazy filled is plenty. BTW Antony are you planning for Backtrace to allow portable runtime *modification* of stack unwinds? Every C++ implementation has an API to do that in its runtime, it's just not normally exposed to the running program. I've been a long time advocate that it ought to be, mainly because of the raw undiluted untrammeled power for potential abuse it hands to the programmer (yes, yes, I really can handle the power, and no, I really really promise to not do evil ... :). Many years ago I tried to persuade WG14 to standardise that API as it's generally in the major C compilers too, but they refused on the basis that such a facility would be horribly abused and it must not be encouraged. Which sounds magic to my ears. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/