This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: RFA[threads]: Fork event updates, part the thirteenth
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: gdb-patches at sources dot redhat dot com
- Cc: Michael Snyder <msnyder at redhat dot com>, kettenis at gnu dot org
- Date: Thu, 9 Jan 2003 14:16:13 -0500
- Subject: Re: RFA[threads]: Fork event updates, part the thirteenth
- References: <20021215213952.GA3923@nevyn.them.org> <3E1A1710.7E0B931@redhat.com> <20030107005055.GA2981@nevyn.them.org>
On Mon, Jan 06, 2003 at 07:50:55PM -0500, Daniel Jacobowitz wrote:
> 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.
Having convinced myself of this, I've checked in the patch as-is.
Thanks. Now for the testcase it fixes.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer