The Science of Debugging
Chapter 6


6.5.6 Starting GDB on an Already Running Program

I hesitated actually including this, but since the default setup for CircleMUD includes the debugging flags, it may actually be useful to do once in a while, especially if you think you're in an infinite loop.

First, run gdb and load the program (don't run it!). You need to specify the binary so the debugger can load the symbol table and know the names of the variables and functions at each memory address, and the sort. Next, use the 'attach' command to attach gdb to a specific PID. This is how I'd do it (locate the PID, and attach to it):

$ ps -auxww |grep circle
dughi 995 0.4 2.4 3928 3204 pts/0 S 07:13 0:01 ./bin/circle 4000
$ gdb bin/circle
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...

(gdb) attach 995
Attaching to program: /home/dughi/circle/circle/bin/circle, Pid 995
Reading symbols from /lib/libcrypt.so.1...done.
Reading symbols from /lib/libc.so.6...done.
Reading symbols from /lib/ld-linux.so.2...done.
BR> Reading symbols from /lib/libnss_files.so.2...done.
0x400f254e in __select () from /lib/libc.so.6
(gdb)






















There we go, attached to the process and ready to debug as if we just hit a breakpoint. Now, exactly where we hit a breakpoint differs from time to time. 'attach' simply stops the program where ever it is. From here, you can use all the normal commands just as if you had started the program from gdb in the beginning.

Note that I said "stops the process". Just like a normal breakpoint, the program is now suspended. If you have any users on, they're quickly going to be disconnecting. If you quit gdb, instead of exiting the program, gdb will simply detach from it, allowing the MUD to continue on it's merry way without a debugger slowing it down.

You may get a few messages like this in your MUD logs though:

Jan 14 07:22:59 :: SYSERR: Missed 233 seconds worth of pulses.


Index
6.1.4.5 Altering Data in a Running Program 7 Before You Start Debugging with MSVC (Visual Studio)