Subject: Re: [boost] [stacktrace] Two days remaining before review ends
From: Antony Polukhin (antoshkka_at_[hidden])
Date: 2017-03-30 06:15:00
2017-03-25 12:02 GMT+03:00 mbartosik via Boost <boost_at_[hidden]>:
> Maybe the author can answer the issues that I raised:
> * 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
Interface of boost::stacktrace::frame provides all the functionality
for writing your own to_string() functions. Can not really understand
> * 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
Thanks in advance for the review!
-- Best regards, Antony Polukhin