I'm using CLion to develop a combined C / Rust program. The program spins off a number of processes that I need to debug. The normal way to do it is to start the main process, have it fork a process, then manually click Run / Attach to Process, search for the forked process, click it and then everything works fine.
This is slow and tedious. Is it possible to set an option somewhere that will automatically attach to a named process?
I'm using LLDB on a Mac.
Related
I would like to debug a C++ program in VSCode. The problem is this program is run as part of a large and messy build system that spawns many processes and prepares input for the program. In other words if I run:
./do the_task
It will compile a load of C++, generate some input and eventually - through several layers of Bash, Python and Makefiles - run something like this:
/very/long/path/to/the_task --lots --of --arguments /very/long/path/to/generated_input.xml
I'd like to debug that process using VSCode/GDB, in such a way that I can
Set breakpoints in the_task.cpp
Just click "Start debugging" with the launch.json set to run do the_task
Unfortunately that doesn't work because by default GDB doesn't follow child processes. You can tell it to but then it will halt the parent process so that only a single process runs at a time. That causes everything to get stuck at some point in my case.
Some ideas I've had:
Is there a way to tell GDB to run a script when a new inferior (process) starts, check the executable name and then detach from the child if it doesn't match?
I could create a proxy GDB/MI wrapper that pretends to VSCode that the program has been started (so the connection doesn't time out), and then when we get to running /very/long/path/to/the_task prefix it with gdb --interpreter=mi and forward on all of the cached commands (to set breakpoints etc.) This seems like quite a lot of work and quite hacky so I'm not sure I like it.
Prefix /very/long/path/to/the_task with gdbserver. Then I can connect to it from VSCode. This is definitely the simplest and most obvious solution but the UX sucks - you have to manually start the command, then wait, then click "start debugging". Plus you're inevitably going to run into port reuse annoyances.
3, but write a custom VSCode extension that automatically starts debugging when it detects gdbserver has started. I've done this for Python debugging so it does work but there are some minor annoyances (e.g. if you restart VSCode and it restores a terminal session it doesn't work). Also it's a fair amount of work.
Is there an obvious solution I'm missing?
I have a C++ project in Visual Studio 2008 that, when executed, spawns another process (due to a GUI library that is being used). However when I exit the main process (either using Ctrl-C or by stopping the debugger), the spawned process (and hence the GUI) remains. This is a side-effect of the library being used, and the nature of the project - it is designed to be embedded, and hence never really "exit", but debugging and testing is Windows-based. The orphan process then stops me being able to run the software again, without first killing it.
Using Process Explorer I can see that the spawned process is a child of the process being debugged. I would like a way to, when I end debugging of a project, kill all child processes.
The Chromium project has a macro which will grab child processes in order to attach to them. This is designed to be associated with a button in the VS GUI, and seems to be chrome-specific (that is, you would need a different button for a different project/parent-process).
I have looked into using the DebuggerProcessEvents::OnProcessStateChanged macro, the idea being that when the debugger stops I could walk through the child processes using a similar idea to the Chromium macro and <evil voice>kill them</evil voice>... but this event never seems to be triggered.
Any thoughts? The project is Makefile-based, due to the code being generated outside of Visual Studio, so I will be limited in the options I can set project-wise.
I have application that has two executables. One that we launch and it forks n instances of the other.
Now I have to debug the second tsk file at launch. I can do it later using the attach to process option. But during launch, there seems to be some memory stuff that I need to debug.
Is there a way to do this.
If you link your program with the dbfork library, totalview should automatically attach to the forked process.
See “Linking with the dbfork Library” contained in the “Compilers and Platforms” Chapter of the TotalView Reference Guide.
I am new to programming.
I know only Start debug before. Maybe start debug suit for some small application develop better.
I found Visual studio IDE provide another method of attach to process for using.
When & Why must I use the attach debugging?
Such as multi-threading application debugging. Client/Service application debugging. etc. Thank you.
Sometimes you need to debug a process started by another program.
For example you need a reliable solution and in order to protect against access violations, memory leaks and other barely recoverable stuff, you have a master program and several worker programs. The master program starts the worker program and passes parameters to it. How do you debug a worker program which is not intended to be started by anything except the master program?
You use "attach to process for that".
Typically you do it this way: insert a statement that blocks the worker program for some time - for example, call Sleep() for 15 seconds. Then you kindly ask the master program to start the worker program. When the worker program is started it blocks and you now have 15 seconds to attach to it.
This way you can debug almost any issues - problems at early startup stages, wrong parameters, etc, which you wouldn't reliably reproduce with "run with debugging".
Attaching to a process is useful if you don't want to debug right from starting the process. For example, debugging usually slows down execution, so it can be quicker to start the app, get it to a state where a bug appears, and then attach a debugger.
It's also useful if you already have an external means of launching the process that you don't want or can't to import into the IDE.
Start debugging from VS launches an instance of the VS webserver and attaches the debugger to it.
Attach to process allows you to attach to any process and debug it, usually you'd do this to your instance of w3wp.exe running your code in IIS
Attach to process is mostly used when you can't run the application from Visual Studio.
For example, if it's a service or if it is a process that has run for a long time and now you want to start debugging it.
Sometimes you also want to debug a remote process, not on your machine - and you can do that using attach to process.
I have a main C++ app built in Visual Studio 2005, called A.exe. It spawns a child process, B.exe. I run process A in the debugger by hitting F5 -- the only way I know to hit breakpoints in process B is to wait for A to kick it off, then run Debug -> Attach to Process, and manually select B.exe. This doesn't work very well if I need to debug initialization code in process B -- I have to start putting in 10 second sleeps at the beginning.
Is there some trick in the vs2005 GUI that I'm missing?
I'm using native code, by the way.
Thanks,
Nathan
You can tell Windows to automatically attach the debugger when a certain process is started (by specifying the process name in a registry setting).
The details are here:
http://msdn.microsoft.com/en-us/library/a329t4ed(v=vs.100).aspx
You'd be hard pushed to make use of the debugbreak command in the child process as the debug process is not yet attached.
However, there is another that may be of use. Seeing as your creating the process, you'll have the handle to it. So give the DebugBreakProcess function a whirl.