From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3850 invoked by alias); 20 Nov 2008 14:29:16 -0000 Received: (qmail 3531 invoked by uid 22791); 20 Nov 2008 14:29:13 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate5.de.ibm.com (HELO mtagate5.de.ibm.com) (195.212.29.154) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 20 Nov 2008 14:28:29 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate5.de.ibm.com (8.13.8/8.13.8) with ESMTP id mAKESPi5421864 for ; Thu, 20 Nov 2008 14:28:25 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id mAKESPEH3829954 for ; Thu, 20 Nov 2008 15:28:25 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id mAKESPMo013066 for ; Thu, 20 Nov 2008 15:28:25 +0100 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with SMTP id mAKESPGZ013059; Thu, 20 Nov 2008 15:28:25 +0100 Message-Id: <200811201428.mAKESPGZ013059@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Thu, 20 Nov 2008 15:28:24 +0100 Subject: Re: Fix foll-fork.exp foll-vfork.exp fork-child-threads.exp To: pedro@codesourcery.com (Pedro Alves) Date: Thu, 20 Nov 2008 23:52:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org In-Reply-To: <200811201328.13651.pedro@codesourcery.com> from "Pedro Alves" at Nov 20, 2008 01:28:13 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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-11/txt/msg00555.txt.bz2 Pedro Alves wrote: > 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. Funny, I was debugging the very same problem just yesterday ... In my case, the wild store clobbered a struct breakpoint for the thread event breakpoint. > pending_follow.kind = TARGET_WAITKIND_SPURIOUS; > if (follow_fork ()) > should_resume = 0; > + > + /* Following a fork may change inferior_ptid. */ > + tp = inferior_thread (); > break; I guess the "regcache" and "gdbarch" variables now also contain stale information. That's not an actual problem right now, as regcache is (currently) not used after this point, and gdbarch (today) will never actually change -- but in order to reduce potential future problems, I think those should also be reset. Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com