dynamic link libs loaded by dlopen seem not to be auto-loaded in the debugger so break points not hit.

[Aymonz]

Operating System: Ubuntu 20.04.2 LTS
Kernel: Linux 5.4.0-73-generic
Architecture: x86-64

VSCode Version: 1.56.2
Commit: 054a9295330880ed74ceaedda236253b4f39a335
Date: 2021-05-12T16:45:26.313Z
Electron: 12.0.4
Chrome: 89.0.4389.114
Node.js: 14.16.0
V8: 8.9.255.24-electron.0
OS: Linux x64 5.4.0-73-generic

Extension version: 1.6.4

i am remote debugging an application in a docker container, the behavior i am seeing is that the first attachment, if it is before parts of the code that loads custom .so libs using dlopen, then attachment seems successful but break points in these libs are not hit, even though the program continues normally indicating the correct .so files are loaded and running.

doing an "image list" to check the loaded objects i can see my custom .so libs are missing and also "ld-linux-x86-64.so.2" is not loaded .. so somehow dynamic loading of libs in the debuggee is not felt in the debugger but the libs are loaded normally in the app (i thought the default behavior of lldb is that dynamic libs are loaded in the debugger as they are loaded in runtime automatically)

if i just detach and reattach again things work as expected (now the debugger feels everything that is loaded) .. so problem happens only first time after application launch

i was using the launch configs in this project as they are for long time, so when they suddenly started doing this behavior i tried to revert the extension to veriosn 1.6.1, and then everything was working good like before. so some how the problem was introduced between 1.6.1 and 1.6.4

Thanks for all your great work, and please tell me if i should send any more info

[vadimcn]

I've tests for this exact scenario, and they work fine. Do you see any modules in the MODULES panel when debugging?

Can you please attach a verbose log?

[Aymonz]

Problem_ext_1_6_4_AttachBeforeLibsLoaded.txt
NoProblem_ext_1_6_1_AttachBeforeLibsLoaded.txt
Problem_ext_1_6_4_AttachAfterLibsLoaded.txt

Thanks for your response .. i attached the 3 verbose logs for 3 cases, but let me describe the cases

• for all i have 1 breakpoint in the dynamic loaded lib.
• i run the app inside the docker container
• i then attach the debugger at different times, with different versions of the extension

Now i describe the 3 logs:

• "NoProblem_ext_1_6_1_AttachBeforeLibsLoaded.txt": this is the log with extension 1.6.1, which is functioning correctly, i run the app in the container, attach the debugger to the process before the dynamic lib is loaded, the breakpoint is hit when the lib is loaded .. worth saying that i don't see any .so files loaded in the Modules panel (is the modules panel used in ext 1.6.1?)
• "Problem_ext_1_6_4_AttachBeforeLibsLoaded.txt": this is the log with extension 1.6.4, where the problem happens, i run the app in the container, attach the debugger to the process before the dynamic lib is loaded, the breakpoint is NOT hit when the lib is loaded but the application is running correctly. the debugger seems attached because i see the threads and i see .so files under modules panel, but breakpoints in the dynamic lib are not hit
• "Problem_ext_1_6_4_AttachAfterLibsLoaded.txt": this is the log with extension 1.6.4, where the problem happens, i run the app in the container, attach the debugger to the process after the dynamic lib is loaded and seems running, the breakpoint is hit and the debugger seems attached (i see the threads and i see .so files under modules panel)

Note: my dynamic lib name is "libdrivesim_uss_model_debug.so" and the dynamic loader is "ld-linux-x86-64.so.2" .. and i can find them in "NoProblem_ext_1_6_1_AttachBeforeLibsLoaded.txt", and in "Problem_ext_1_6_4_AttachAfterLibsLoaded.txt" .. but not in "Problem_ext_1_6_4_AttachBeforeLibsLoaded.txt"

i beg your pardon that I couldn't create a simplified version of my app that highlights the problem, because it will take me some time that i didn't have, but i hope this can help you identify the issue .. let me know if i can send more data

[vadimcn]

Sounds like the problem is in the LLDB engine itself. I've updated it to v13.0.0 in CodeLLDB 1.6.6, maybe the bug got fixed...