HP made good hardware. And I got spoiled.

I'm trying to debug in gdb on linux, and currently
trying to debug a child process after a call to fork.

gdb has a setting for "set follow child" so gdb will
follow the child process to debug.

This all works great on HPUX, where I gain most of
my gdb experience.

It doesn't work on linux. (until kernel 2.5.60)
(http://developer.apple.com/documentation/DeveloperTools/gdb/gdb/gdb_5.html)

Their are other features of gdb like catchpoints, which
appear to be HPUX only.

To debug child processes, I found these notes.
http://plug.org.in/pipermail/plug-mail/2001-December/002079.html

]Taken from gdb manual :
]
]"GDB has no special support for debugging programs
]which create additional processes using the fork
]function. When a program forks, GDB will continue to
]debug the parent process and the child process will
]run unimpeded. If you have set a breakpoint in any
]code which the child then executes, the child will get
]a SIGTRAP signal which (unless it catches the signal)
]will cause it to terminate."
]
]But there is also a workaround mentioned.
]Read gdb manual at :
]http://www.gnu.org/manual/gdb-4.17/html_chapter/gdb_5.html#SEC26



and this for ddd (X gui front to gdb)
http://www.cs.toronto.edu/~maclean/csc209/ddd-gdb-children.html

]Using gdb/ddd to debug child processes
]If you have tried to debug a child process using ddd, you may have
]noticed that ]ddd steps into the parent (and not the child) after
]the call to fork(). It is ]possible to debug the child as well, but
]it requires a special procedure. Since ]the child is a separate
]process, it will require a second debugger window, and we will
]make use of gdb's ability to "attach" to a process which is already
]running.
]
]Before you start, you must do the following:
]
]Make sure your call to fork() assigns a value to some variable so
]you can read ]it easily, e.g. "pid = fork()".
]Make sure you place a sleep() statement in the child as the first
]line of code ]after the fork(), e.g. "sleep(60)" make the sleep()
]long enough for step 4 below .... The sleep() statment can be
]removed once debugging is complete.
]Compile your program with the "-g" option set,
]e.g. gcc myProg.c -o myProg -g
]Now you are ready to start:
]Start 2 copies of ddd in the background, like
]   "ddd myProg & ddd myProg &". It is important that the two
]copies being running concurrently.
]
]Pick (arbitrarily) one window to be the "parent" and set a
]breakpoint after the call to fork() (but not in any code the
]child will be executing ... that is, set the breakpoint somewhere
]in the parent's code ... if you set the breakpoint in the child's
]code, DDD will kill the child as soon as it is created!).
]Run the parent to the breakpoint. Note the value returned by fork(),
]i.e. the process ID of the child.
]
]In the "child" window, type "attach <pid>" in the gdb console
]window where <pid> is the child's process ID. Note: the gdb
]console is found at the bottom of the ddd window; this is where
]you can type commands directly to gdb.
]
]Set a breakpoint in the child after the sleep() statement, and
]click on "cont" (in the popup "Command Tool" window) to allow
]the child to continue execution to the breakpoint.

Instead of calling sleep directly, not knowing how long I'll
fumble to get to attaching to the child process, I use code like this:

for ( x = 1; x; )
{
    sleep(5);
    printf ( "Child %d x=%d\n", getpid(), x );
}

Then I can detach and attach to child at my speed,
set a breakpoint, set x to 0, and continue.

Keven

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *