From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13898 invoked by alias); 1 Dec 2008 19:01:09 -0000 Received: (qmail 13616 invoked by uid 22791); 1 Dec 2008 19:01:08 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-outbound-2.vmware.com (HELO smtp-outbound-2.vmware.com) (65.115.85.73) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 01 Dec 2008 19:00:33 +0000 Received: from mailhost3.vmware.com (mailhost3.vmware.com [10.16.27.45]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id 2D86B3D006; Mon, 1 Dec 2008 11:00:30 -0800 (PST) Received: from [10.20.92.151] (promb-2s-dhcp151.eng.vmware.com [10.20.92.151]) by mailhost3.vmware.com (Postfix) with ESMTP id 23038C9A84; Mon, 1 Dec 2008 11:00:30 -0800 (PST) Message-ID: <493433D7.7080803@vmware.com> Date: Mon, 01 Dec 2008 19:01:00 -0000 From: Michael Snyder User-Agent: Thunderbird 1.5.0.12 (X11/20080411) MIME-Version: 1.0 To: Pedro Alves CC: "gdb-patches@sourceware.org" Subject: Re: Fix foll-fork.exp foll-vfork.exp fork-child-threads.exp References: <200811201328.13651.pedro@codesourcery.com> In-Reply-To: <200811201328.13651.pedro@codesourcery.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-12/txt/msg00008.txt.bz2 Pedro Alves wrote: > Long story short: > > After following a child, detaching from the parent, > > ('set follow-fork-mode child' + 'set detach-on-fork on') > > here in this bit, > > infrun.c:resume(): > { > .... > follow_fork (); > ... > tp->stop_signal = TARGET_SIGNAL_0; > } > > ... `tp' is no longer in the thread list (it was pointing at a thread > of the parent process, which we've detached from, hence no longer > in the thread list), so if the assignment above doesn't crash, it ends > up writing to who-knows-where. > > With some local changes I was making, sometimes, `tp' happened to be left pointing > at linux_nat.c:lwp_list, and so that assignment above ended up clearing > lp->waitstatus.kind (of the first lwp in the list), which resulted in > GDB considering that the child process had > exited (because TARGET_SIGNAL_0 == TARGET_WAITKIND_EXITED). > > This should fix intermittent foll-fork.exp foll-vfork.exp > fork-child-threads.exp failures. > > Checked in. Pedro, I'm not sure if this change goes far enough. If a multi-threaded program forks, only the currently executing thread survives in the child. All others are left behind (and its not unlikely that the thread library is left in an inconsistant state, possibly leading to deadlocks). We can't do anything about that, but we could, eg., invalidate all known debugger state having to do with other threads. Clear the gdb thread list and preserve only the current thread. What do you think? > ------------------------------------------------------------------------ > > 2008-11-20 Pedro Alves > > * infrun.c (resume): If following a fork, reread the current > thread. Avoid dereferencing a possibly dangling pointer. > > --- > gdb/infrun.c | 7 +++++-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > Index: src/gdb/infrun.c > =================================================================== > --- src.orig/gdb/infrun.c 2008-11-20 05:37:35.000000000 +0000 > +++ src/gdb/infrun.c 2008-11-20 12:30:26.000000000 +0000 > @@ -1053,6 +1053,9 @@ a command like `return' or `jump' to con > pending_follow.kind = TARGET_WAITKIND_SPURIOUS; > if (follow_fork ()) > should_resume = 0; > + > + /* Following a fork may change inferior_ptid. */ > + tp = inferior_thread (); > break; > > case TARGET_WAITKIND_EXECD: > @@ -1148,11 +1151,11 @@ a command like `return' or `jump' to con > displaced_step_dump_bytes (gdb_stdlog, buf, sizeof (buf)); > } > > - target_resume (resume_ptid, step, sig); > - > /* Avoid confusing the next resume, if the next stop/resume > happens to apply to another thread. */ > tp->stop_signal = TARGET_SIGNAL_0; > + > + target_resume (resume_ptid, step, sig); > } > > discard_cleanups (old_cleanups);