2017-04-11 1:41 GMT+03:00 mbartosik via Boost
*Address space layout randomization*
There problem here is that boost::stacktrace::safe_dump_to must be async-signal-safe but getting the ASLR independent offset often requires calling dl* functions that are not async-signal-safe. I'll try to investigate further, probably there's some trick that I'm not aware of.
*Use on non-current threads:*
This is currently out of scope of the library. Main reasons are * portability - this looks extremely unportable * safety - this looks extremely unsafe and may lead to deadlocks/terminates * usefulness - does not look like many users want that feature
To collect a stack in a different thread I know is possible and portably because I've seen it done on most platforms (this is what a debugger does when it dumps the stack of a target process).
Think of it as of a surgery. It is kind-of simple to make a surgery if you are not doing it to yourself. So yes, free standing debugger process can stop threads, place breakpoints, investigate variables, modify code on the fly, change registers from other threads. But doing that from the process to itself... not sure that computer science is ready for the experience of Leonid Rogozov. At least not in the version 1.0 of the Boost.Stacktrace.
This is why the ReadMemory argument in Microsoft's StackWalk64 API is provided.
Yep, DbgHelp library has lethal amount of irony in it: StackWalk64 has interface to do threads debugging, but can not do that because it is located in a DbgHelp library that is single threaded.
*Out of the box caching:*
Oh, you're talking about that kind of caching. There's a plan to allow that using Thread Local Storage https://github.com/apolukhin/stacktrace/issues/11 I'll definitely do that some day soon.
*Control over what frame::to_string / frame::name do * What I was thinking was whether there should be some user control over how the name for the frame is reported e.g. bar(int), void bar(int), void namespace::bar(int), bar(), __stdcall void bar(int), ?bar@@YAH@Z This is not something that I consider particularly important, it might be food for thought for you.
Such customization must be applied to a low level boost/core/demangle.hpp header first. As soon as such customization appear in there, I'll add that to the stacktrace interface.
I know that this is quite a bit of comment and that the official review period is over (I was getting married plus honey moon while the review was on). I do think this is an great addition to have in boost.
Thanks a lot for the comments! I really appreciate those, they help to make the library better. -- Best regards, Antony Polukhin