[llvm-dev] lldb stops on every call to dlopen

[Steve Ravet via llvm-dev]

Hello lldb developers, I am running into a problem with lldb on Linux.  I am currently running llvm 6.0.0.

I have an executable that dynamically loads a large number of shared libraries at runtime.  These are explicitly loaded via dlopen (they are specified in a configuration file), and after loading a few (typically a dozen or so, but the number varies) lldb will halt during dlopen.  If I continue, it will load a few more then halt again, which makes debugging from startup impractical since there are so many libraries to be loaded (more than a hundred of them).

When I build and debug this same C++ on macOS, the debugger works fine.  I have verified that target.process.stop-on-sharedlibrary-events is false. I turned on dyld logging and I see lots of log messages about RendezvousBreakpoint being hit, but I don’t see anything that sheds light on why some libraries load without stopping but others don’t.

I have tried to recreate this in a trivial program that calls dlopen in a loop, but haven’t been able to reproduce.

Can your offer any suggestions for further debugging this?  More supporting evidence follows.

Here is the message when the debugger stops:

Process 120004 stopped
* thread #1, name = ‘xxxxxxxx', stop reason = trace
    frame #0: 0x00002aaaacfca6a0 libc.so.6`__restore_rt
libc.so.6`__restore_rt:
->  0x2aaaacfca6a0 <+0>: movq   $0xf, %rax
    0x2aaaacfca6a7 <+7>: syscall 
    0x2aaaacfca6a9 <+9>: nopl   (%rax)

libc.so.6`__libc_sigaction:
    0x2aaaacfca6b0 <+0>: subq   $0xd0, %rsp

I do not have the stop on shared library events setting enabled:

(lldb) settings show target.process.stop-on-sharedlibrary-events
target.process.stop-on-sharedlibrary-events (boolean) = false



The backtrace goes back to dlopen:

(lldb) bt
* thread #1, name = ‘xxxxx', stop reason = trace
  * frame #0: 0x00002aaaacfca6a0 libc.so.6`__restore_rt
    frame #1: 0x00002aaaaaab9eb0 ld-linux-x86-64.so.2
    frame #2: 0x00002aaaaaabdc53 ld-linux-x86-64.so.2`dl_open_worker + 499
    frame #3: 0x00002aaaaaab9286 ld-linux-x86-64.so.2`_dl_catch_error + 102
    frame #4: 0x00002aaaaaabd63a ld-linux-x86-64.so.2`_dl_open + 186
    frame #5: 0x00002aaaac39df66 libdl.so.2`dlopen_doit + 102
    frame #6: 0x00002aaaaaab9286 ld-linux-x86-64.so.2`_dl_catch_error + 102
    frame #7: 0x00002aaaac39e29c libdl.so.2`_dlerror_run + 124
    frame #8: 0x00002aaaac39dee1 libdl.so.2`__dlopen_check + 49

the dyld debug log has a lot of this:
209 intern-state     DynamicLoaderPOSIXDYLD::RendezvousBreakpointHit pid 153501 stop_when_images_change=false
210 intern-state     DynamicLoaderPOSIXDYLD::RendezvousBreakpointHit called for pid 153501
211 intern-state     DYLDRendezvous::Resolve address size: 8, padding 4
212 intern-state     DYLDRendezvous::Resolve cursor = 0x2aaaaaccc160
213 intern-state     DynamicLoaderPOSIXDYLD::RendezvousBreakpointHit pid 153501 stop_when_images_change=false
214 intern-state     DynamicLoaderPOSIXDYLD::RendezvousBreakpointHit called for pid 153501
215 intern-state     DYLDRendezvous::Resolve address size: 8, padding 4
216 intern-state     DYLDRendezvous::Resolve cursor = 0x2aaaaaccc160



thanks,
--steve


 In the woods too, a man casts off his years, as the snake his slough, and at what period soever of life, is always a child.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180416/ce42ab6a/attachment.html>