我正在开发一个C ++应用程序，该应用程序将使用多个子进程，并且这些子过程必须由父进程产生，以便可以正确设置管道。目前，我的孩子流程正在启动中崩溃。我以前已经能够运行VSCODE调试器，并让它在外部或信号上打破并从那里进行调试。但是令我恐惧的是，我发现如果您要调试父程流程，那显然是不起作用的，因为没有什么可以看孩子的过程。
过去两天，我已经厌倦了互联网上的问题。
- 显然，
cppvsdbg debugger（我一直在使用它，因为这是Windows上的MSVC项目，我什至还没有到达跨平台部分）不支持调试子流程，尽管自2017年以来就提出了的功能请求 ！即使是奇怪的铬和边缘开发团队也陷入了这一线程，仍然没有。
- 此外，我无法添加上述功能，因为
vsdbg 幕后使用的程序是封闭源 。
- 我显然不能使用gdb，因为需要程序 program 可以构建视野studio-code/“ rel =“ nofollow noreferrer”> gcc/g ++而不是msvc ，我已经在这个愚蠢的cmake构建系统上累积地工作了一个月，以使其实际上使它变得函数。
- 我试图在Visual Studio中运行我的程序，但无法弄清楚如何实际运行它。在Cmake领域中，VS太深了，甚至显然无法理解它。
- 我尝试使用QT Creator的调试器*调试程序*，因为它显然可以在发现其启动的那一刻可以附加到程序上，但是子过程崩溃的速度如此之快，以至于不会抓住东西80时间的百分比和其他20％的时间不会在崩溃中断裂。
- 我已经将大约五个调试扩展程序安装到Vscode中，以尝试获取 的功能，但是每个人都以新的和不同的方式失败，直到包括
lldb 需要所有事物的 python python 的终止版本才能函数。
我在这里失去理智。请告诉我，我缺少一些东西，或者我忽略了一些明显的东西。该项目实际上已经处于起步阶段，如果我找不到某种方法来调试所有过程，那么它将在将来增加开发问题。
*我也会用QT标记此标签，因为我正在使用Qprocess来产生孩子的过程，但这并不是实际引起问题的原因。
I'm developing a C++ application which is going to use multiple child processes, and these child processes must be spawned by the parent process so that pipes can be set up correctly. Currently, my child process is crashing somewhere in startup. I've previously been able to just run the VSCode debugger and just let it break on the exception or signal and debug things from there. But to my horror, I found out that apparently that doesn't work if you're debugging the parent process, as nothing watches the child process.
I've spent the past two days getting fed up with the internet over this problem.
- Apparently the
cppvsdbg debugger (which I've been using as this is an MSVC project on Windows, and I haven't even gotten to the cross platform part yet) does NOT support debugging a child process despite having a feature request for it SINCE 2017!! Even the freaking Chrome and Edge dev teams chimed in on this thread and still nothing.
- There's additionally no way I can ADD the above feature, because the
vsdbg program used behind the scenes is closed source.
- I apparently can't use GDB because that requires the program to be built in gcc/g++ and not MSVC, and I've already spent about a month cumulatively working on this stupid CMake build system to actually get it to function.
- I've tried to run my program in Visual Studio and couldn't figure out how to actually get it to run. It's far too deep in CMake territory for VS to even understand it apparently.
- I've tried to debug my program using Qt Creator's debugger*, as it has a thing that can apparently attach to a program the moment it detects it starting, but the subprocess is just crashing so fast that it doesn't catch the thing 80% of the time, and the other 20% it doesn't breakpoint on the crash.
- I've installed about five other debugging extensions into VSCode trying to get something to function, but every single one of them has failed in a new and different way, up to including
lldb requiring an end-of-life'd version of python of all things in order to even function.
I'm losing my mind here. Please tell me there's something I'm missing, or something obvious I'm overlooking. This project is literally in its infancy and if I can't find some method to debug all the processes going forward, it's just going to multiply the development problems in the future.
*I'll tag this with Qt as well because I'm using QProcess to spawn the child process, but that's not what's actually causing the problem here.
发布评论
评论（1）
在 VSCode 功能请求 MPI 调试支持的讨论中，子进程调试器扩展 被提及。
按照手动安装步骤（这是 2024 年 8 月）后，我成功启动了 Windows 调试会话（使用 VS Build Tools 2022 附带的调试器）。它目前处于预发布状态并且仅限于 Windows，但它允许您在进程之间切换和控制进程（通过堆栈跟踪区域中的下拉菜单）、设置断点并单独单步执行每个进程。
请测试并参与讨论，以完善此扩展并发布以供广泛采用！
In the discussion in the VSCode feature request for MPI debugging support, the Child Process Debugger extension gets mentioned.
After following the steps for manual installation (this is August 2024), I was successful in launching a Windows debugging session (using the the debugger that comes VS Build Tools 2022). It is currently in pre-release state and limited to Windows, yet it allows you to switch between and control processes (via the drop-downs in the stack trace area), set breakpoints and step each process separately.
Please test and participate in the discussions to get this extension polished and published for broad adoption!