Re: [boost] [stacktrace] Two days remaining before review ends

Subject: Re: [boost] [stacktrace] Two days remaining before review ends
From: Antony Polukhin (antoshkka_at_[hidden])
Date: 2017-04-12 19:02:23

2017-04-11 1:41 GMT+03:00 mbartosik via Boost <boost_at_[hidden]>:
> *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_at_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