[boost] [stacktrace] Partial review

Subject: [boost] [stacktrace] Partial review
From: Florian Weimer (fw_at_[hidden])
Date: 2017-03-25 13:29:00

* 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.

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.

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.

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.

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.