Subject: Re: [boost] [stacktrace] Partial review
From: Antony Polukhin (antoshkka_at_[hidden])
Date: 2017-03-26 17:32:15
2017-03-25 16:29 GMT+03:00 Florian Weimer via Boost <boost_at_[hidden]>:
> * Niall Douglas via Boost:
>> - What is your evaluation of the implementation?
> I had a cursory look at the implementation.
> addr2line_pipe uses fork and fdopen, which are not async-signal-safe
> with glibc. But then, std::string is used as well, which is not
> async-signal-safe, either, so maybe that's okay.
Methods that use fork and fdopen are marked as async-signal-unsafe.
> addr2line_pipe uses execvp, which could lead to evaluation of the PATH
> variable from programs which underwent an AT_SECURE transition (e.g.,
> SUID programs), which could lead to privilege escalation issues.
I'm providing an absolute path to the executable, so there must be no
PATH evaluation. Am I missing something?
> With inlining, a single stack frame can expand to a list of source
> locations (reflecting the inlineed call stack). The current design
> does not take that into account.
I've found no system API to get multiple locations. So the Stacktrace
API is designed to have at most 1 location.
> Success of dladdr does not mean that it has obtained useful
> information. You really need to call addr2line in that case as well.
> Furthermore, before calling addr2line, you have to translate the
> address to an object-relative address (again with the help of dladdr).
> The current code assumes that addresses in the main object (without
> dli_sname) are not subject to ASLR, which is not true for
> position-independent executables.
> The libunwind unwinder does not use _Unwind_GetIPInfo, and it does not
> seem to deal with the function call/signal handler frame difference.
Hm. Looks I have to experiment a little bit more. Thanks for pointing that out.
> The documentation should perhaps say something about dlclose. If an
> application formats the stack trace for human consumption, but this
> happens after stack unwinding, some DSOs may have been closed with
> dlclose, and it could be impossible to obtain symbol information at
> that point.
Ok. Good point.
-- Best regards, Antony Polukhin
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk