Bug ID: 40609
           Summary: LLDB stops on every call to dlopen() when the process
                    has additional threads running under kernel 4.20
           Product: lldb
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         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
(lldb) r
Process 11913 launched: '/home/franz/Documents/lldbrep/lldb_stop' (x86_64)
Creating thread...
Thread successfully created
Loading shared library...
Process 11913 stopped
* thread #1, name = 'lldb_stop', stop reason = shared-library-event
    frame #0: 0x00007ffff7fe23e0`__GI__dl_debug_state`__GI__dl_debug_state:
->  0x7ffff7fe23e0 <+0>: endbr64 
    0x7ffff7fe23e4 <+4>: retq`.annobin_dl_debug.c:
    0x7ffff7fe23e5 <+5>: nopw   %cs:(%rax,%rax)`_dl_debug_initialize:
    0x7ffff7fe23f0 <+0>: endbr64 
  thread #2, name = 'lldb_stop', stop reason = signal SIGSTOP
    frame #0: 0x00007ffff7f920c6`do_futex_wait.constprop.1 + 54`do_futex_wait.constprop.1:
->  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

Reply via email to