From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26502 invoked by alias); 6 Jan 2003 23:54:06 -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 26427 invoked from network); 6 Jan 2003 23:54:05 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by 209.249.29.67 with SMTP; 6 Jan 2003 23:54:05 -0000 Received: from int-mx2.corp.redhat.com (nat-pool-rdu-dmz.redhat.com [172.16.52.200]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h06NQJB06373 for ; Mon, 6 Jan 2003 18:26:19 -0500 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h06Nrqn24760; Mon, 6 Jan 2003 18:53:52 -0500 Received: from redhat.com (reddwarf.sfbay.redhat.com [172.16.24.50]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id h06Nrqn24134; Mon, 6 Jan 2003 15:53:52 -0800 Message-ID: <3E1A1710.7E0B931@redhat.com> Date: Mon, 06 Jan 2003 23:54:00 -0000 From: Michael Snyder Organization: Red Hat, Inc. X-Accept-Language: en MIME-Version: 1.0 To: Daniel Jacobowitz CC: gdb-patches@sources.redhat.com, kettenis@gnu.org Subject: Re: RFA[threads]: Fork event updates, part the thirteenth References: <20021215213952.GA3923@nevyn.them.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2003-01/txt/msg00245.txt.bz2 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? Michael > > -- > Daniel Jacobowitz > MontaVista Software Debian GNU/Linux Developer > > 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)));