Bug ID: 40609
Summary: LLDB stops on every call to dlopen() when the process
has additional threads running under kernel 4.20
Component: All Bugs
Created attachment 21436
Reproduction case that stops when calling dlopen()
Since updating to Linux kernel 4.20, if a program is run under LLDB and calls
dlopen() after spawning additional process threads LLDB will stop on every call
to dlopen() with the reason "shared-library-event", even though
target.process.stop-on-sharedlibrary-events is set to false. Attempts to
continue results in additional stops with the reason being either additional
shared-library-events or SIGSTOP. If halting on SIGSTOP is disabled in LLDB,
the program will eventually complete the dlopen() call successfully and run
normally. Calling dlopen() from a single-threaded program results in no
This only occurs under kernel 4.20. When running the same program under kernel
4.19 no issues are exhibited. GDB doesn't stop under the same conditions and
the test program shows no errors with the various Clang sanitizers or Valgrind.
I've reproduced this on two separate machines with both the stable LLDB 7.0.1
as well as a recent build of the trunk.
The output of LLDB when running a small reproduction case (included as an
attachment), which spawns a single thread and loads a minimal shared library,
is as follows:
(lldb) target create "lldb_stop"
Current executable set to 'lldb_stop' (x86_64).
(lldb) settings show target.process.stop-on-sharedlibrary-events
target.process.stop-on-sharedlibrary-events (boolean) = false
Process 11913 launched: '/home/franz/Documents/lldbrep/lldb_stop' (x86_64)
Thread successfully created
Loading shared library...
Process 11913 stopped
* thread #1, name = 'lldb_stop', stop reason = shared-library-event
frame #0: 0x00007ffff7fe23e0 ld-2.28.so`__GI__dl_debug_state
-> 0x7ffff7fe23e0 <+0>: endbr64
0x7ffff7fe23e4 <+4>: retq
0x7ffff7fe23e5 <+5>: nopw %cs:(%rax,%rax)
0x7ffff7fe23f0 <+0>: endbr64
thread #2, name = 'lldb_stop', stop reason = signal SIGSTOP
frame #0: 0x00007ffff7f920c6 libpthread.so.0`do_futex_wait.constprop.1 + 54
-> 0x7ffff7f920c6 <+54>: cmpq $-0x1000, %rax ; imm = 0xF000
0x7ffff7f920cc <+60>: ja 0x7ffff7f920e8 ; <+88>
0x7ffff7f920ce <+62>: movl %r12d, %edi
0x7ffff7f920d1 <+65>: callq 0x7ffff7f92aa0 ;
You are receiving this mail because:
You are the assignee for the bug.
lldb-dev mailing list