2017-03-25 12:02 GMT+03:00 mbartosik via Boost
Maybe the author can answer the issues that I raised:
Here: http://boost.2283326.n4.nabble.com/Stacktrace-review-comments-td4692904.html
* Control of how aggressive stack walking is.
I know only one stack walking strategy - the least aggressive. It's the user responsibility to make stack walking possible by building the debug version of the library, or providing OS specific files, or building with specific flags. Otherwise no stack will be collected.
* Ability to walk stack of another thread including in another process.
You can collect stack in current thread and move/copy it to other thread using interthread/inteprocess communications. Walking the stack of a thread that you have no control of is out of current library scope as there's no known to me portable ways to do so. Any suggestions would be appreciated.
* boost::stacktrace::frame::to_string should be efficient for 2nd and 3rd and multiple calls, but not require more than a single pointer to be stored in the boost::stacktrace::frame. This implies either a different class for symbol resolution or external caching.
No out of the box caching, but user can write code for external caching. I'd appreciate suggestions on how to implement caching on a library level but without new class additions.
* Control over what boost::stacktrace::frame::to_string includes (or define it).
Interface of boost::stacktrace::frame provides all the functionality for writing your own to_string() functions. Can not really understand your request.
* Ability to work with post-mortem data. e.g. serialize a boost::stacktrace plus other information (a list of modules) and then deserialize and resolve symbols after the process has exited.
boost::stacktrace::safe_dump_to functions implement that functionality.
* Work with boost serialization
This must be done in Boost.Serialization library, not in the Stacktrace library.
If I have a vote it would depend on the answers to these questions, without good answers it would be a no vote. I'm getting on a flight soon, so I'll won't be able to comment more until Sunday.
Thanks in advance for the review! -- Best regards, Antony Polukhin