[Bug 1894159] [NEW] lldb API uses wrong executable filename
Public bug reported:
I've noticed that some of my debugging scripts that use lldb to launch
and debug processes don't work and hang indefinitely on Ubuntu Focal
with latest llvm toolchain installed.
The culprit is the fact that lldb API tries to launch a binary named
"lldb-server-10.0.0" which doesn't exist (installing lldb installs lldb-
server as a symlink to lldb-server-10 , but not lldb-server-10.0.0).
This becomes apparent when logging is enabled for the debugger:
1599167975.387668848 python 0x238adc0
Listener::StartListeningForEvents (broadcaster = 0x236c6f0, mask = 0x00020004)
acquired_mask = 0x00020004 for lldb.process.gdb-remote.async-listener
1599167975.387677193 python successfully created process
1599167975.387685061 python setting up hijacker
1599167975.387690544 python 0x238b500
Listener::Listener('lldb.PlatformLinux.DebugProcess.hijack')
1599167975.387698174 python 0x02369F20
Broadcaster("lldb.process")::HijackBroadcaster
(listener("lldb.PlatformLinux.DebugProcess.hijack")=0x0238B500)
1599167975.387704611 python launching process with the following file
actions:
1599167975.387755871 python 0x0236C170
Communication::Disconnect ()
1599167975.387762785 python Process::SetPublicState (state =
launching, restarted = 0)
1599167975.387876272 python shlib dir -> `/usr/lib/x86_64-linux-gnu/`
1599167975.387891054 python HostInfo::ComputePathRelativeToLibrary()
attempting to derive the path /bin relative to liblldb install path:
/usr/lib/x86_64-linux-gnu
1599167975.387899160 python HostInfo::ComputePathRelativeToLibrary()
derived the path as: /usr/lib/bin
1599167975.387925148 python support exe dir -> `/usr/bin/`
1599167975.387954235 python process launch failed: unable to locate
lldb-server-10.0.0
This issue is simply resolved by making yet another symlink to lldb-server to
point to lldb-server-10.0.0 but without logging enabled, it isn't obvious where
the problem is.
This behavior can be observed by executing the attached python script
(slightly modified lldb example from https://lldb.llvm.org/use/python-
reference.html).
Expected behavior is that breakpoint is set and hit, but due to missing
lldb-server-10.0.0 binary, the process is never launched.
** Affects: llvm-toolchain-10 (Ubuntu)
Importance: Undecided
Status: New
** Attachment added: "sample script that demonstrates the issue"
https://bugs.launchpad.net/bugs/1894159/+attachment/5407505/+files/test.py
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1894159
Title:
lldb API uses wrong executable filename
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-10/+bug/1894159/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1894166] [NEW] libasan missing debug symbols break debugging
Public bug reported: By default, all symbols are missing from libasan binary that is installed with this package. This, among other things, effectively breaks debugging with gdb (and LLDB , but that doesn't matter). To be able to catch ASAN errors in GDB , one would break on "__sanitizer::Die" and go from there, but without symbols, this won't work. Other tools rely on symbol lookups to determine instrumentation presence , which would fail in this case as well. For example, without libasan5-dbgsym installed: (gdb) break __sanitizer::Die Function "__sanitizer::Die" not defined. Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 1 (__sanitizer::Die) pending. (gdb) r ... ASAN REPORT ... ==1802381==ABORTING [Inferior 1 (process 1802381) exited with code 01] However, with libasan5-dbgsym installed: (gdb) break __sanitizer::Die Breakpoint 1 at 0x776bc200: file ../../../../src/libsanitizer/sanitizer_common/sanitizer_termination.cc, line 49. (gdb) r ... ASAN REPORT ... ==1805058==ABORTING Breakpoint 1, __sanitizer::Die () at ../../../../src/libsanitizer/sanitizer_common/sanitizer_termination.cc:49 49 ../../../../src/libsanitizer/sanitizer_common/sanitizer_termination.cc: No such file or directory. (gdb) bt #0 __sanitizer::Die () at ../../../../src/libsanitizer/sanitizer_common/sanitizer_termination.cc:49 #1 0x7769d8ec in __asan::ScopedInErrorReport::~ScopedInErrorReport (this=0x7fffd156, __in_chrg=) at ../../../../src/libsanitizer/asan/asan_report.cc:185 #2 0x7769d363 in __asan::ReportGenericError (pc=93824992236075, bp=bp@entry=140737488346576, sp=sp@entry=140737488346560, addr=106034152603909, is_write=is_write@entry=false, access_size=access_size@entry=1, exp=0, fatal=true) at ../../../../src/libsanitizer/asan/asan_report.cc:192 #3 0x7769de4b in __asan::__asan_report_load1 (addr=) at ../../../../src/libsanitizer/asan/asan_rtl.cc:116 #4 0x522b in main () (gdb) In this example, it's fairly obvious that missing symbols will prevent one to put a breakpoint on __sanitizer::Die , but as I mentioned, checks in other tools would fail silently and the issue isn't immediately traceable back to missing symbols. Since AddressSanitizer is primarily used for debugging anyway, would it make sense to have libasan with symbols by default? ** Affects: gcc-9 (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1894166 Title: libasan missing debug symbols break debugging To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gcc-9/+bug/1894166/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
