- It might be that we'll want to debug a program that cannot be launched from the command line. This may be because the program is launched from some system daemon (such as a CGI program on the web), and we are too lazy to make it possible to run it directly from the command line. Or perhaps the program takes very long time to run its initialization code, and starting it with a debugger attached to it will cause this startup time to be much much longer.
- In order to do that, we will launch the debugger in this way:
$gdb debugme 9561
Here we assume that "debugme" is the name of the program executed, and that 9561 is the process id (PID) of the process we want to debug.
- What happens is that gdb first tries looking for a "core" file named "9561", and when it won't find it, it'll assume the supplied number is a process ID, and try to attach to it.
- If there process executes exactly the same program whose path we gave to gdb (not a copy of the file. it must be the exact same file that the process runs), it'll attach to the program, pause its execution, and will let us continue debugging it as if we started the program from inside the debugger.
- Doing a "where" right when we get gdb's prompt will show us the stack trace of the process, and we can continue from there.
- Once we exit the debugger, It will detach itself from the process, and the process will continue execution from where we left it.
Cem Ozdogan
2011-02-14
