2017-03-25 16:29 GMT+03:00 Florian Weimer via Boost <boost@lists.boost.org>:
* 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