From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22916 invoked by alias); 14 Oct 2009 21:16:49 -0000 Received: (qmail 22903 invoked by uid 22791); 14 Oct 2009 21:16:47 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 14 Oct 2009 21:16:44 +0000 Received: (qmail 9519 invoked from network); 14 Oct 2009 21:16:42 -0000 Received: from unknown (HELO orlando) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 14 Oct 2009 21:16:42 -0000 From: Pedro Alves To: Paul Pluzhnikov Subject: Re: [patch] Fix for internal-error: linux_nat_post_attach_wait: Assertion `pid == new_pid && WIFSTOPPED (status)' failed. Date: Wed, 14 Oct 2009 21:16:00 -0000 User-Agent: KMail/1.9.10 Cc: gdb-patches@sourceware.org References: <20091013184120.30A5776761@ppluzhnikov.mtv.corp.google.com> <200910142007.59636.pedro@codesourcery.com> <8ac60eac0910141401l57a6285es75634cf40ea5142d@mail.gmail.com> In-Reply-To: <8ac60eac0910141401l57a6285es75634cf40ea5142d@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200910142216.46073.pedro@codesourcery.com> 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: 2009-10/txt/msg00318.txt.bz2 On Wednesday 14 October 2009 22:01:05, Paul Pluzhnikov wrote: > On Wed, Oct 14, 2009 at 12:07 PM, Pedro Alves wrote: > > > Ugh. Happened much more often for me, like 1 in 5... > > It's racy. I've seen different frequency of problems depending on > whether I run kernel 2.6.24 or 2.6.30. > Yeah. > > I don't think you needed the interface change. > > Indeed. > > > Back to the "simple" variant: The inferior just added is > > always inferior_ptid/current_inferior(). If you look > > at fork-child.c:startup_inferior, you'll see bits of > > code doing exactly what you'd need to do. E.g.: > > > > target_terminal_ours (); > > target_mourn_inferior (); > > if (WIFEXITED (status)) > > error (_("During startup program exited with code %d."), > > WIFEXITCODE (status)); > > else if (WIFSIGNALED (status)) > > error (_("During startup program exited with signal ..."), > > ...); > > I don't see above code in fork-child.c (or anywhere else for that > matter). Are you looking at a local patch? Well, you won't find that that _exactly_, as it was a copy-paste-tweak. But I pointed you in the right direction anyway, it seems. :-) > Anyway, here is try #3. Awesome. Almost perfect. > + delete_lwp (ptid); FYI, this isn't necessary. linux_nat_mourn_inferior takes care of deleting all lwps of the inferior being mourned already. > + error (_("During startup program exited normally.")); > + else > + error (_("During startup program exited with code %d."), > + exit_code); > + } > + else if (WIFSIGNALED (status)) > + { > + int signo = WTERMSIG (status); > + > + target_terminal_ours (); > + target_mourn_inferior (); > + error (_("During startup program terminated with signal %s, %s."), I didn't mean to use those strings exactly. Please remove or replace "During startup" with something else. We're attaching, not starting up. Sorry, I'll remember that my telepatic module is broken and to be more specific next time. ;-) Okay with that fixed. -- Pedro Alves