0

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.

Den-Jason
  • 2,395
  • 1
  • 22
  • 17
Tustin2121
  • 2,058
  • 2
  • 25
  • 38
  • Use WinDbg and attach to process. Obviously you would need to add a delay to the start of the child process to give you time to attach the debugger to it. See https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/debugging-a-user-mode-process-using-windbg – Den-Jason Apr 12 '22 at 23:30
  • Another thing could be to get the child process to log to e.g. "proc_.log" (with a flush after each call) so you could identify _where_ the code is breaking. – Den-Jason Apr 12 '22 at 23:34
  • Also, I wouldn't necessarily assume that `QProcess` (or QT for that matter) isn't doing something stupid behind the scenes - especially if it's designed around Linux/Posix/PThreads and uses kludges to adapt to the Windows API. I believe I've seen similar issues in mingw-w64 and cross-platform libraries which do not particularly adapt well to the Windows API - particularly Windows Sockets. – Den-Jason Apr 12 '22 at 23:45
  • @Den-Jason Thanks for the comments. I did try WinDbg but couldn't wrap my head around it, especially after how convenient vscode makes debugging (hover over vars, etc). I could I suppose throw printlns into every line of code (I have stderr redirected properly to see logs), but the purpose of using a debugger is to avoid having to do that. And I ruled out QProcess as the culprit already as I know roughly where the crash is happening in the subprocess, but I don't know why, and this is usually the part where I go in with a debugger and poke at variables and step through; and thus my problem. – Tustin2121 Apr 13 '22 at 01:20
  • 1
    Like GDB, WinDbg can be off-putting (in terms of "where to start?") but it's worth investing some time. Take a look at some resources such as https://www.youtube.com/watch?v=sTjZPjVnVVU I've used it to step through device drivers; it's really quite amazing to halt an _entire machine_ in the debugger :) – Den-Jason Apr 13 '22 at 07:18
  • The other alternative is to attach to the process with Visual Studio (not VS-Code). The main thing to suss out is telling the debugger to locate the source and PDB files (see https://stackoverflow.com/a/11090873/1607937). You could even try something wacky as suggested here -> https://stackoverflow.com/a/44022995/1607937 – Den-Jason Apr 13 '22 at 07:23
  • Also see https://stackoverflow.com/questions/33865329/how-to-get-pdb-files-while-compiling-release-version-of-static-library-using-cma – Den-Jason Apr 13 '22 at 07:25

0 Answers0