addr2line -f fails with "InvalidDebugSymbols(SubroutineMissingName(0, 100459))"

[slonopotamus]

Way to reproduce:

wget http://slonopotamus.org/libUE4Editor-Core.so
addr2line -f -e libUE4Editor-Core.so 0x2c09b2

Expected output (as produced by addr2line from GNU binutils and gdb, and I know this is correct result):

_Z20PlatformCrashHandleriP9siginfo_tPv
/home/marat/production/ue4/Engine/Source/Runtime/Core/Private/Linux/LinuxPlatformCrashContext.cpp:595

Actual output:

addr2line: Error(Msg("failed to analyze debug information"), State { next_error: Some(Error(Msg("encountered invalid compilation unit"), State { next_error: Some(Error(InvalidDebugSymbols(SubroutineMissingName(0, 100459)), State { next_error: None, backtrace: None })), backtrace: None })), backtrace: None })

Note that running without -f switch properly resolves filename/lineno, it's only function name that fails to resolve.

Funny facts:

1. addr2line from elfutils works in the opposite way: it resolves function name but fails with filename/lineno.
2. addr2line from elftoolchain segfaults when trying to resolve function name, and gives wrong filename/lineno.
3. addr2line from FreeBSD gives wrong filename/lineno and fails to find function name

So, among five addr2line implementations, there are no two that behave the same way.

[philipc]

I think we need to follow DW_AT_specification references, similar to the way we currently handle DW_AT_abstract_origin.

[slonopotamus]

I've tested the fix you provided in #36 and indeed addr2line now can resolve function name, however it takes pretty lots of time to do that.

binutils:

$ time addr2line -f -e libUE4Editor-Core.so 0x2c09b2
_Z20PlatformCrashHandleriP9siginfo_tPv
/home/marat/production/ue4/Engine/Source/Runtime/Core/Private/Linux/LinuxPlatformCrashContext.cpp:595

real    0m0.085s
user    0m0.060s
sys     0m0.020s

gimli-rs (release):

$ time ./target/release/addr2line -f -e libUE4Editor-Core.so 0x2c09b2
_Z20PlatformCrashHandleriP9siginfo_tPv
/home/marat/production/ue4/Engine/Source/Runtime/Core/Private/Linux/LinuxPlatformCrashContext.cpp:595

real    0m0.321s
user    0m0.310s
sys     0m0.010s

gimli-rs (debug):

$ time ./target/debug/addr2line -f -e libUE4Editor-Core.so 0x2c09b2
_Z20PlatformCrashHandleriP9siginfo_tPv
/home/marat/production/ue4/Engine/Source/Runtime/Core/Private/Linux/LinuxPlatformCrashContext.cpp:595

real    0m9.073s <-- holy cow!
user    0m8.830s
sys     0m0.020s

Note that it's function name resolving being slow. If -f switch is omitted, even debug gimli-rs is faster than binutils.

Would you like me to create a separate issue regarding performance?

On the positive side, you're the fastest among addr2line implementers who made a fix :)

[philipc]

debug builds will be slow. We don't care about performance for it.

The release build is slower for a single address, but faster for multiple addresses. Here's the benchmark for the same library testing 26069 different addresses:

==> Benchmarking
binutils  nofunc  4.00  172868
master    nofunc  0.22  30228
==> Benchmarking with -f
binutils  func  4.10   172852
master    func  1.19   70344

Is performance for single addresses something you care about? There's definitely room for improvement there, but not sure if it is worth the effort. If you do care about it, please create a separate issue.

[philipc]

Oh, for that benchmark, the third column is time in seconds, the fourth column is memory usage in kilobytes.

[slonopotamus]

For future readers: actually, there is one more addr2line implementation (although with different command line args) - llvm-symbolizer. It is consistent with binutils and (after #36) also with gimli.