From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19335 invoked by alias); 7 Jan 2003 00:50:57 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 19328 invoked from network); 7 Jan 2003 00:50:56 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by 209.249.29.67 with SMTP; 7 Jan 2003 00:50:56 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18Vjpk-0004pk-00; Mon, 06 Jan 2003 20:51:16 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18VhxH-0000nN-00; Mon, 06 Jan 2003 19:50:55 -0500 Date: Tue, 07 Jan 2003 00:50:00 -0000 From: Daniel Jacobowitz To: Michael Snyder Cc: gdb-patches@sources.redhat.com, kettenis@gnu.org Subject: Re: RFA[threads]: Fork event updates, part the thirteenth Message-ID: <20030107005055.GA2981@nevyn.them.org> Mail-Followup-To: Michael Snyder , gdb-patches@sources.redhat.com, kettenis@gnu.org References: <20021215213952.GA3923@nevyn.them.org> <3E1A1710.7E0B931@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E1A1710.7E0B931@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-01/txt/msg00248.txt.bz2 On Mon, Jan 06, 2003 at 03:53:52PM -0800, Michael Snyder wrote: > Daniel Jacobowitz wrote: > > > > Now is where it starts to get interesting. Michael, I mentioned this patch > > to you at lunch last week. If you take a short-lived program, run it, and > > detach it, and run it again, you'll see the exit of the _previous_ copy. > > Then GDB gets hopelessly confused. I have a testcase for this which I'll > > post in a moment. > > > > The reason it's included here is that that's essentially what happens if you > > are using "set follow-fork-mode child". We detach from the parent, which > > exits, confusing GDB. > > > > Is this OK? > > Hi Dan, > > Please excuse the delay. This seems OK. In child_wait, > would it be possible to add a check to see if the exiting > process is in our lwp list? I _think_ that child_wait will never be called if there is anything in the LWP list; if we have LWPs, we'll have pushed thread_db onto the stack, and we'll go to lin_lwp_wait instead if thre are any LWPs. But I'm sleepy, so I may be missing something; I'll sit on this and look at it again tomorrow :) Thanks. > > 2002-12-15 Daniel Jacobowitz > > > > * lin-lwp.c (child_wait): Ignore exit statuses for processes other > > than inferior_ptid. > > (lin_lwp_wait): Ignore exit statuses for unknown LWPs. > > > > Index: lin-lwp.c > > =================================================================== > > RCS file: /cvs/src/src/gdb/lin-lwp.c,v > > retrieving revision 1.39 > > diff -u -p -r1.39 lin-lwp.c > > --- lin-lwp.c 9 Dec 2002 18:41:42 -0000 1.39 > > +++ lin-lwp.c 15 Dec 2002 21:16:34 -0000 > > @@ -964,6 +964,14 @@ child_wait (ptid_t ptid, struct target_w > > pid = waitpid (GET_PID (ptid), &status, __WCLONE); > > save_errno = errno; > > > > + /* Make sure we don't report an event for the exit of the > > + original program, if we've detached from it. */ > > + if (pid != -1 && ! WIFSTOPPED (status) && pid != GET_PID (inferior_ptid)) > > + { > > + pid = -1; > > + save_errno = EINTR; > > + } > > + > > clear_sigio_trap (); > > clear_sigint_trap (); > > } > > @@ -1091,6 +1099,17 @@ lin_lwp_wait (ptid_t ptid, struct target > > gdb_assert (pid == -1 || lwpid == pid); > > > > lp = find_lwp_pid (pid_to_ptid (lwpid)); > > + > > + /* Make sure we don't report an event for the exit of an LWP not in > > + our list, i.e. not part of the current process. This can happen > > + if we detach from a program we original forked and then it > > + exits. */ > > + if (! WIFSTOPPED (status) && ! lp) > > + { > > + status = 0; > > + continue; > > + } > > + > > if (! lp) > > { > > lp = add_lwp (BUILD_LWP (lwpid, GET_PID (inferior_ptid))); > -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer