Potential issue: Stacktrace on Linux via addr2line won't work when process is looked up via PATH

[Schreischildkroete]

Not sure if this can be considered a design issue or it's working as intended. However, when a stack trace is printed the line number an/or symbols can only be resolved via addr2line, when the process is NOT resolved via PATH. Otherwise the symbols are not correctly resolved, because internally the process is not found via addr2line.

If you need more information please feel free to ask.

[apolukhin]

That's strange. addr2line based implementation uses dladdr for getting the symbol location. And that approach usually returns an absolute path via dli_fname.

What OS are you using? Is it Android?

[j-jr-richter]

Problem exists also on SLE-15 (SUSE Linux Enterprise).

Root cause is that for the main program dli_fname is not absolute andhence addr2line fails.

This small patch fixes it for me:

--- /usr/include/boost/stacktrace/detail/addr2line_impls.hpp    2018-05-25 20:30:40.000000000 +0200
+++ boost/stacktrace/detail/addr2line_impls.hpp 2020-07-22 10:43:25.242050818 +0200
@@ -114,7 +114,7 @@
     std::string res;
 
     boost::stacktrace::detail::location_from_symbol loc(addr);
-    if (!loc.empty()) {
+    if (!loc.empty() && strchr(loc.name(), '/') != NULL) { // for programs started through $PATH loc.name() is not absolute and addr2line will fail
         res = loc.name();
     } else {
         res.resize(16);