Re-attach debugger to parent process after child exits

[nyurik]

When debugging a complex multi-process code like Rust compiler unit tests, the current settings set target.process.follow-fork-mode child|parent is too limiting because a compiler test does a tree-like traversal - forking a subprocess which may spawn another subprocess, waiting for the child to finish, and forking another process and waiting for that, etc. If the follow mode is child, it will stop debugging when the first child exits. If it is the parent, it will never go into any child processes.

Thus, it is currently impossible to add a breakpoint to the code and wait for it to be hit - because it might be in the second child process that runs.

Would it be possible for the debugger to re-attach to the parent process once the child exits?

See also

• Unable to debug Rust Clippy's unit tests due to `error while loading shared libraries` vadimcn/codelldb#1231
• Debugging child processes vadimcn/codelldb#317

[llvmbot]

@llvm/issue-subscribers-lldb

Author: Yuri Astrakhan (nyurik)

When debugging a complex multi-process code like Rust compiler unit tests, the current `settings set target.process.follow-fork-mode child|parent` is too limiting because a compiler test does a tree-like traversal - forking a subprocess which may spawn another subprocess, waiting for the child to finish, and forking another process and waiting for that, etc. If the follow mode is `child`, it will stop debugging when the first child exits. If it is the `parent`, it will never go into any child processes.

Thus, it is currently impossible to add a breakpoint to the code and wait for it to be hit - because it might be in the second child process that runs.

Would it be possible for the debugger to re-attach to the parent process once the child exits?

See also

• Unable to debug Rust Clippy's unit tests due to `error while loading shared libraries` vadimcn/codelldb#1231
• Debugging child processes vadimcn/codelldb#317

[DavidSpickett]

I think @labath worked on these settings.

[jimingham]

I wouldn't do it this way. lldb supports multiple processes simultaneously so it seems like a much more natural flow for your use case would be to continue debugging the parent, and add the child as a separate target in that debug session.

IIRC, the only reason it was done this way was expediency. But if we're going to go another round with this feature, we should not force users to make the unnecessary choice between parent and child.

[jimingham]

That would also be much simpler to implement than trying to recover the parent you've forgotten about on child exit.