Re: Problems debugging forked processes

[Frank Schaefer <frank dot schafer at setuza dot cz>]

On Fri, 2002-04-19 at 18:10, Daniel Jacobowitz wrote:
> On Fri, Apr 19, 2002 at 09:45:49AM +0200, Frank Schaefer wrote:
> > Hi there,
> > 
> > I've written a network daemon and client. The daemon forks to serve a
> > client request.
> > Everything runs fine outside of the debugger, but I want to trace the
> > code at least once, before I release it.
> > 
> > Here goes my problem:
> > # gdb daemon
> > GNU gdb 5.0
> > Copyright 2000 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 "i686-pc-linux-gnu"...
> > (gdb) b 13
> > Breakpoint 1 at 0x8048899: file daemon.c, line 13.
> > (gdb) show follow-fork-mode
> > Debugger response to a program call of fork or vfork is "parent".
> > (gdb) set follow-fork-mode child
> > (gdb) show follow-fork-mode
> > Debugger response to a program call of fork or vfork is "child".
> 
> This variable doesn't actually affect GNU/Linux.  Yeah, I know, I know. 
> We need a documentation patch to address this; please file a PR
> (http://sources.redhat.com/gdb/, Bugs).
> 
> > If I use the attach method from a second instance of gdb ( there's the
> > sleep() above for ), the child process exits on exceptions ( mostly
> > segmentation fault and sometimes invalid operation ) on different
> > (random???) lines in the code. This happens everytime in the fixup()
> > from ld.linux.so.
> 
> Because the breakpoints which were inserted when the application forked
> turn into traps.  There's no clear solution to this without actually
> implementing fork-following - which should not be hard, but no one has
> stepped up to do it.

O.K.,

I had a look at sources.redhat.com.
Maybe I'll have a look at the GDB-code too. Just now I don't have the
time. The fork related stuff should be in inftarg.c, fork-child.c and
infptrace.c for GNU/Linux right?

For now I use this workaround.

RetVal = fork();
if( RetVal ) printf( "%d\n", RetVal ); else sleep( 10 );
... further code

I start the daemon outside of gdb, and attach the child to a gdb session
after the PID is printed, having the first breakpoint somewhere in the
"further code". That's not very nice but at least it works for me.

Regards and thanks for the hints
Frank