codelldb

codelldb copied to clipboard

When running integration tests on a rust exe, the tests will invoke separate processes to start the executable. This is good because it's testing the external interface, but it really sucks for debugging.

E.g.: https://github.com/ChrisGreenaway/cargo-local-registry/blob/master/tests/all.rs

(As far as I know this approch is the 'right' way to code integration tests for a command line app in rust)

Is there a way that we can launch a child process from a debugged rust process and somehow flag to the debugger that we'd really really like you to debug that also?

(I guess the follow up question is could we then hide that implementation in a crate so that it could support a range of debuggers.)

I don't think we should change how rust does the integration testing because there are many other times where I've created a subprocess that I'd ideally like to be included in the debugging session by default.

If we could find a nice mechanism for this it would be a real step forward for debugging.

Prior art: https://marketplace.visualstudio.com/items?itemName=vsdbgplat.MicrosoftChildProcessDebuggingPowerTool

LLDB does not support child debugging; this isn't something I can implement in the extension on my own. You could try this though. Not as convenient, but does the job.

LLDB does not support child debugging; this isn't something I can implement in the extension on my own. You could try this though. Not as convenient, but does the job.

I've spent literally hours trying to get this working to no avail. I can only get the debugger to attach if I manually breakpoint and copy out the PID and open the URI in a shell. Is there really no way for this to be exposed via the extension by monitoring what child processes the target has?

Is there really no way for this to be exposed via the extension by monitoring what child processes the target has?

Not really. Intercepting fork() and attaching to the child process before it starts executing requires debugger support. If you don't care about such things, you can probably create a script that does the monitoring and starts new debug sessions.

Not really. Intercepting fork() and attaching to the child process before it starts executing requires debugger support.

In my case I'm starting the application suspended anyways, but I see your point! It's not a very tenable solution for the plugin for sure. Real shame there's not support for this in lldb, via testing it seems like debugging multiple processes works well aside from needing to invoke URIs.

I've spent literally hours trying to get this working to no avail.

For people who may run into the same issue as I did: Trying to invoke a URI to debug a child process fails if lldb is connected to the parent process already and that parent was launched through vscode on Windows. Think it to be a kernel issue, as it appears the URI never arrives, but it's not very clear to me.

If opening the URI does not work, you can try the RPC server option.

lldb now supports this: https://github.com/llvm/llvm-project/commit/4a2a947317bf702178bf1af34dffd0d280d49970

lldb now supports this: llvm/llvm-project@4a2a947

I saw this, but unfortunately it's Linux only and doesn't support Mac OS or Windows. At least not as of that commit, not sure it's been expanded since then. My primary use is so I can debug injected payloads in Windows apps though, as I'm typically working on QoL patches for older games – so unfortunately RPC and URI solutions are the only workarounds for now.

Would also love to see this, but can understand that it may need to be implemented one level lower.

Discussions:

• https://discourse.llvm.org/t/rfc-support-debugging-child-processes/65506
• https://discourse.llvm.org/t/rfc-more-complete-multiprocess-support-in-lldb/61061/10

Wrote a workaround using an extension that listen to process tree and auto attaches https://marketplace.visualstudio.com/items?itemName=thebestnom.auto-attach-child-processes (it does means that it will not attach on start but it is good enough for me 😅)

@thebestnom I tried the extension, it does seem to work but uses too much memory and eventually crashes on large applications that spawn many processes (like Chromium). I will continue to keep trying it out though.

I came across this: https://stackoverflow.com/questions/74366554/debug-a-c-child-process-using-vs-code has it actually worked for anyone?

If you're using LLDB or codeLLDB, here is the LLDB command that mirrors the above except the detach feature:

{
    "configurations": [
        {

            "initCommands": [
                "settings set target.process.follow-fork-mode child"
            ]
        }
    ]
}

@jasonwilliams as for my extension open issue there, I can probably make it way quicker and more efficient, it's not the most complicated thing 😂

As for the follow fork, it allows lldb to follow the child by debugging it instead of the main process

Thanks @thebestnom I've added an idea here https://github.com/thebestnom/vscode-auto-attach-child-processes/issues/1. As for follow fork, you're right, that won't be useful for this usecase