Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Paul Pluzhnikov <ppluzhnikov@google.com>
To: Pedro Alves <pedro@codesourcery.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [patch] Fix for internal-error: linux_nat_post_attach_wait:  	Assertion `pid == new_pid && WIFSTOPPED (status)' failed.
Date: Wed, 14 Oct 2009 18:21:00 -0000	[thread overview]
Message-ID: <8ac60eac0910141121r59573032na0ccee77f049366f@mail.gmail.com> (raw)
In-Reply-To: <200910132153.51171.pedro@codesourcery.com>

[-- Attachment #1: Type: text/plain, Size: 1580 bytes --]

On Tue, Oct 13, 2009 at 1:53 PM, Pedro Alves <pedro@codesourcery.com> wrote:

>> 2009-10-13  Paul Pluzhnikov  <ppluzhnikov@google.com>
>>
>>       * linux-nat.c (linux_nat_post_attach_wait): Adjust assert.
>>

> Sorry, but this isn't correct.

Thanks for review and explanations.

> I think what we should do is just get rid of the new
> LWP that we found exiting right after attaching.

I believe the new patch below achieves that.

It's very hard to test, since it only happens once in about 50
attaches, but I did catch this several times, and GDB appears to
have done the right thing.

> I would believe that we can also see the main LWP exit right
> after attach (in linux_nat_attach).  I'm not sure what exactly
> is the best to do UI wise in that case.  If we want to store
> the event pending to report later, we'll have to use
> the lwp->waitstatus field, not lwp->status, due to the
> fact that lwp->status == 0 is ambiguous with
> "no-stored-pending-event" (see status_callback).

I believe I did this now. Not sure whether lp->resumed should also
be set here.

> The simple
> alternative is to again just pretend that the process had
> exited before we managed to attach to it, get rid of it,
> and error out like we would if the process didn't exist
> at all when we tried to attach.

This appears harder to do, since to_attach doesn't return anything.

Thanks,
-- 
Paul Pluzhnikov

2009-10-14  Paul Pluzhnikov  <ppluzhnikov@google.com>

	* linux-nat.c (linux_nat_post_attach_wait): Return
	success/failure indicator.
	(lin_lwp_attach_lwp, linux_nat_attach): Adjust.

[-- Attachment #2: gdb-assert-10757-20091014.txt --]
[-- Type: text/plain, Size: 3127 bytes --]

Index: linux-nat.c
===================================================================
RCS file: /cvs/src/src/gdb/linux-nat.c,v
retrieving revision 1.151
diff -u -p -u -r1.151 linux-nat.c
--- linux-nat.c	9 Oct 2009 01:57:12 -0000	1.151
+++ linux-nat.c	14 Oct 2009 18:06:26 -0000
@@ -1289,14 +1289,13 @@ pid_is_stopped (pid_t pid)
 }
 
 /* Wait for the LWP specified by LP, which we have just attached to.
-   Returns a wait status for that LWP, to cache.  */
+   Returns 1 if LWP has been stopped, else 0.  */
 
 static int
-linux_nat_post_attach_wait (ptid_t ptid, int first, int *cloned,
-			    int *signalled)
+linux_nat_post_attach_wait (ptid_t ptid, int first, int *status,
+			    int *cloned, int *signalled)
 {
   pid_t new_pid, pid = GET_LWP (ptid);
-  int status;
 
   if (pid_is_stopped (pid))
     {
@@ -1327,29 +1326,38 @@ linux_nat_post_attach_wait (ptid_t ptid,
   /* Make sure the initial process is stopped.  The user-level threads
      layer might want to poke around in the inferior, and that won't
      work if things haven't stabilized yet.  */
-  new_pid = my_waitpid (pid, &status, 0);
+  new_pid = my_waitpid (pid, status, 0);
   if (new_pid == -1 && errno == ECHILD)
     {
       if (first)
 	warning (_("%s is a cloned process"), target_pid_to_str (ptid));
 
       /* Try again with __WCLONE to check cloned processes.  */
-      new_pid = my_waitpid (pid, &status, __WCLONE);
+      new_pid = my_waitpid (pid, status, __WCLONE);
       *cloned = 1;
     }
 
-  gdb_assert (pid == new_pid && WIFSTOPPED (status));
+  gdb_assert (pid == new_pid);
 
-  if (WSTOPSIG (status) != SIGSTOP)
+  if (!WIFSTOPPED (*status))
+    {
+      /* The pid we tried to attach has apparently just exited.  */
+      if (debug_linux_nat)
+	fprintf_unfiltered (gdb_stdlog, "LNPAW: Failed to stop %d: %s",
+			    pid, status_to_str (*status));
+      return 0;
+    }
+
+  if (WSTOPSIG (*status) != SIGSTOP)
     {
       *signalled = 1;
       if (debug_linux_nat)
 	fprintf_unfiltered (gdb_stdlog,
 			    "LNPAW: Received %s after attaching\n",
-			    status_to_str (status));
+			    status_to_str (*status));
     }
 
-  return status;
+  return 1;
 }
 
 /* Attach to the LWP specified by PID.  Return 0 if successful or -1
@@ -1395,7 +1403,9 @@ lin_lwp_attach_lwp (ptid_t ptid)
 			    "LLAL: PTRACE_ATTACH %s, 0, 0 (OK)\n",
 			    target_pid_to_str (ptid));
 
-      status = linux_nat_post_attach_wait (ptid, 0, &cloned, &signalled);
+      if (!linux_nat_post_attach_wait (ptid, 0, &status, &cloned, &signalled))
+	return -1;
+
       lp = add_lwp (ptid);
       lp->stopped = 1;
       lp->cloned = cloned;
@@ -1493,8 +1503,13 @@ linux_nat_attach (struct target_ops *ops
   /* Add the initial process as the first LWP to the list.  */
   lp = add_lwp (ptid);
 
-  status = linux_nat_post_attach_wait (lp->ptid, 1, &lp->cloned,
-				       &lp->signalled);
+  if (!linux_nat_post_attach_wait (lp->ptid, 1, &status, &lp->cloned,
+				   &lp->signalled))
+    {
+      store_waitstatus (&lp->waitstatus, status);
+      return;
+    }
+
   lp->stopped = 1;
 
   /* Save the wait status to report later.  */

  reply	other threads:[~2009-10-14 18:21 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-13 18:41 Paul Pluzhnikov
2009-10-13 20:53 ` Pedro Alves
2009-10-14 18:21   ` Paul Pluzhnikov [this message]
2009-10-14 19:08     ` Pedro Alves
2009-10-14 21:01       ` Paul Pluzhnikov
2009-10-14 21:16         ` Pedro Alves
2009-10-14 21:28           ` Paul Pluzhnikov
2009-10-14 22:29             ` Pedro Alves
2009-10-15  2:17               ` Doug Evans
2009-10-15 18:10               ` Paul Pluzhnikov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8ac60eac0910141121r59573032na0ccee77f049366f@mail.gmail.com \
    --to=ppluzhnikov@google.com \
    --cc=gdb-patches@sourceware.org \
    --cc=pedro@codesourcery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox