From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27797 invoked by alias); 22 Apr 2002 05:47:08 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 27789 invoked from network); 22 Apr 2002 05:47:07 -0000 Received: from unknown (HELO violet.setuza.cz) (194.149.118.97) by sources.redhat.com with SMTP; 22 Apr 2002 05:47:07 -0000 Received: from ADMIN.satuza.cz (ADMIN.setuza.cz [2.2.2.21]) by violet.setuza.cz (Postfix) with ESMTP id 05C4773CE6 for ; Mon, 22 Apr 2002 05:47:09 +0000 (UTC) Subject: Re: Problems debugging forked processes From: Frank Schaefer To: gdb@sources.redhat.com In-Reply-To: <20020419121038.A24030@nevyn.them.org> References: <1019202349.3213.5.camel@ADMIN> <20020419121038.A24030@nevyn.them.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Sun, 21 Apr 2002 22:47:00 -0000 Message-Id: <1019454426.310.1.camel@ADMIN> Mime-Version: 1.0 X-SW-Source: 2002-04/txt/msg00354.txt.bz2 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