Open malor opened 2 years ago
I believe the critical bit is here where LLDB gets confused when loading DWARF debugging symbols from /lib64/ld-linux-x86-64.so.2; after that it no longer recognizes the symbol from the dynamic linker shared object and resorts to the default stack unwind method
I don't understand this part: in the official CPython Docker images /lib64/ld-linux-x86-64.so.2
is a symlink to /lib/x86_64-linux-gnu/ld-2.31.so
# ls -la /lib64/
total 8
drwxr-xr-x 2 root root 4096 Dec 1 00:00 .
drwxr-xr-x 1 root root 4096 Dec 20 07:21 ..
lrwxrwxrwx 1 root root 32 Oct 2 12:47 ld-linux-x86-64.so.2 -> /lib/x86_64-linux-gnu/ld-2.31.so
so LLDB should be able to load the DWARF debugging symbols from /lib64/ld-linux-x86-64.so.2
, just like it did for /lib/x86_64-linux-gnu/ld-2.31.so
, but somehow that results in the unknown symbol warning.
However, if I replace the /lib64/ld-linux-x86-64.so.2
symlink with a copy of /lib/x86_64-linux-gnu/ld-2.31.so
, stack traces are still broken, even though the warnings are gone: https://xsnippet.org/QxWuMd8h
... and the tests magically pass on LLDB versions 15 and 16 (#66), but not on 12-14 or 17-19 :( I'll take a closer look to see what is special about those two.
Somehow, LLDB versions 12 and newer downloaded from https://apt.llvm.org/ do not work correctly with the official Python Docker images: they fail to produce a valid stack trace after hitting an arbitrary breakpoint in libpython. From what I can tell, the problem is not with libpython and its debugging symbols, but rather with LLDB erroneously switching to the
x86_64 default unwind plan UnwindPlan
from the expectedeh_frame CFI UnwindPlan
.E.g. this is the output I see when trying to get a CPython-level stack trace for the following snippet of code with a breakpoint set at
builtin_abs()
:I believe the critical bit is here where LLDB gets confused when loading DWARF debugging symbols from
/lib64/ld-linux-x86-64.so.2
; after that it no longer recognizes the symbol from the dynamic linker shared object and resorts to the default stack unwind method:Apparently, it then remembers this decision for CPython frames as well, even though we definitely do have DWARF debugging symbols, and eh_frame-based stack unwinding should be used:
So far I haven't managed to find what exactly causes this problem, but my understanding is that it's not specific to LLDB 12+, as LLDB 13 works just fine on my Arch Linux with CPython 3.10 built from the source code.