NOTE: This patch has been forwardported to RHEL-7.2.  It is originally

  from RHEL-6.7.

  Message-ID: <54E37CE7.50703@redhat.com>

  Date: Tue, 17 Feb 2015 17:39:51 +0000

  From: Pedro Alves <palves@redhat.com>

  To: Sergio Durigan Junior <sergiodj@redhat.com>

  Subject: [debug-list] [PATCH] RH BZ #1162264 - gdb/linux-nat.c:1411:

   internal-error:,

   linux_nat_post_attach_wait: Assertion `pid == new_pid' failed.

  Hi.

  Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1162264

  So I spend a few more hours today trying to reproduce the

  EACCES, to no avail.  Also, unfortunately, none of the attach

  bugs exposed by attach-many-short-lived-threads.exp test

  can explain this.

  It seems to be that really the best we can do is cope with

  the error, like in the patch below.

  Note that the backtrace at

   https://bugzilla.redhat.com/show_bug.cgi?id=1162264#c3 :

  shows that this triggers for the main thread already:

  ...

  #6  0x000000000044fd2e in linux_nat_post_attach_wait (ptid=..., first=1, cloned=0x1d84368,

  ...

  (note "first=1").

  For upstream, I think linux_nat_attach should be adjusted to work

  like gdbserver -- that is, leave the initial waitpid to the main

  wait code, like all other events, instead of synchronously

  doing waitpid(PID).  That'll get rid of linux_nat_post_attach_wait

  altogether.  But that's too invasive for a bug fix.

  >From 072c61aeb9adc64e1eb45c120061b85fbf6f4d25 Mon Sep 17 00:00:00 2001

  From: Pedro Alves <palves@redhat.com>

  Date: Tue, 17 Feb 2015 17:11:05 +0000

  Subject: [PATCH] RH BZ #1162264 - gdb/linux-nat.c:1411: internal-error:

   linux_nat_post_attach_wait: Assertion `pid == new_pid' failed.

  According to BZ #1162264, it can happen that we manage to attach to a

  process, but then waitpid on it fails with EACCES.  That's unexpected,

  and gdb hits an assertion.  But given this is an error that is out of

  our control, we should handle it gracefully.  I wasn't able to

  reproduce the EACCES, but hacking in the error, like:

  |  --- a/gdb/linux-nat.c

  |  +++ b/gdb/linux-nat.c

  |  @@ -1409,7 +1409,7 @@ linux_nat_post_attach_wait (ptid_t ptid, int first, int *cloned,

  | 	   *cloned = 1;

  | 	 }

  | 

  |  -  if (new_pid != pid)

  |  +  if (new_pid != pid || 1)

  | 	 {

  | 	   int saved_errno = errno;

  | 

  |  @@ -1423,6 +1423,7 @@ linux_nat_post_attach_wait (ptid_t ptid, int first, int *cloned,

  | 	   ptrace (PTRACE_DETACH, pid, 0, 0);

  | 

  | 	   errno = saved_errno;

  |  +      errno = EACCES;

  | 	   perror_with_name (_("waitpid"));

  | 	 }

  ... I could confirm that the error handling works properly.  On the

  EACCES case, we get:

   (gdb) attach 1202

   Attaching to process 1202

   Unable to attach: waitpid: Permission denied.

   (gdb) info inferiors

     Num  Description       Executable

   * 1    <null>

   (gdb)

  No test because the conditions that lead to the waitpid error are

  unknown.

  gdb/ChangeLog:

  2015-02-17  Pedro Alves  <palves@redhat.com>

	  * linux-nat.c: Include "exceptions.h".

	  (linux_nat_post_attach_wait): If waitpid returns an excepted

	  result, detach and error out instead of asserting.

	  (linux_nat_attach): Wrap linux_nat_post_attach_wait in TRY_CATCH.

	  Mourn inferior and rethrow in case of error while waiting for the

	  initial stop.

---

 gdb/linux-nat.c | 34 +++++++++++++++++++++++++++++++---

 1 file changed, 31 insertions(+), 3 deletions(-)

Index: gdb-7.6.1/gdb/linux-nat.c

===================================================================

--- gdb-7.6.1.orig/gdb/linux-nat.c

+++ gdb-7.6.1/gdb/linux-nat.c

@@ -1397,7 +1397,22 @@ linux_nat_post_attach_wait (ptid_t ptid,

       *cloned = 1;

     }

-  gdb_assert (pid == new_pid);

+  if (new_pid != pid)

+    {

+      int saved_errno = errno;

+

+      /* Unexpected waitpid result.  EACCES has been observed on RHEL

+	 6.5 (RH BZ #1162264).  This is most likely a kernel bug, thus

+	 out of our control, so treat it as invalid input.  The LWP's

+	 state is indeterminate at this point, so best we can do is

+	 error out, otherwise we'd probably end up wedged later on.

+

+	 In case we're still attached.  */

+      ptrace (PTRACE_DETACH, pid, 0, 0);

+

+      errno = saved_errno;

+      perror_with_name (_("waitpid"));

+    }

   if (!WIFSTOPPED (status))

     {

@@ -1621,7 +1636,7 @@ static void

 linux_nat_attach (struct target_ops *ops, char *args, int from_tty)

 {

   struct lwp_info *lp;

-  int status;

+  int status = 0;

   ptid_t ptid;

   volatile struct gdb_exception ex;

@@ -1659,8 +1674,19 @@ linux_nat_attach (struct target_ops *ops

   /* Add the initial process as the first LWP to the list.  */

   lp = add_initial_lwp (ptid);

-  status = linux_nat_post_attach_wait (lp->ptid, 1, &lp->cloned,

-				       &lp->signalled);

+  TRY_CATCH (ex, RETURN_MASK_ERROR)

+    {

+      status = linux_nat_post_attach_wait (lp->ptid, 1, &lp->cloned,

+					   &lp->signalled);

+    }

+  if (ex.reason < 0)

+    {

+      target_terminal_ours ();

+      target_mourn_inferior ();

+

+      error (_("Unable to attach: %s"), ex.message);

+    }

+

   if (!WIFSTOPPED (status))

     {

       if (WIFEXITED (status))