[patch] Fix for internal-error: linux_nat_post_attach_wait: Assertion `pid == new_pid && WIFSTOPPED (status)' failed.

[patch] Fix for internal-error: linux_nat_post_attach_wait: Assertion `pid == new_pid && WIFSTOPPED (status)' failed.

[Paul Pluzhnikov]

Greetings,

Using test case from http://sourceware.org/bugzilla/show_bug.cgi?id=10757,
Pedro noticed, and I reproduced (this happens rarely):

warning: Can't attach LWP 15338: No such process
../../src/gdb/linux-nat.c:1341: internal-error: linux_nat_post_attach_wait: Assertion `pid == new_pid && WIFSTOPPED (status)' failed.

When assertion fails, status == 0.

Here is a proposed fix.

Thanks,
--
Paul Pluzhnikov

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

	* linux-nat.c (linux_nat_post_attach_wait): Adjust assert.

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	13 Oct 2009 18:18:37 -0000
@@ -1338,16 +1338,22 @@ linux_nat_post_attach_wait (ptid_t ptid,
       *cloned = 1;
     }
 
-  gdb_assert (pid == new_pid && WIFSTOPPED (status));
+  gdb_assert (pid == new_pid);
 
-  if (WSTOPSIG (status) != SIGSTOP)
+  if (WIFSTOPPED (status))
     {
-      *signalled = 1;
-      if (debug_linux_nat)
-	fprintf_unfiltered (gdb_stdlog,
-			    "LNPAW: Received %s after attaching\n",
-			    status_to_str (status));
+      if (WSTOPSIG (status) != SIGSTOP)
+	{
+	  *signalled = 1;
+	  if (debug_linux_nat)
+	    fprintf_unfiltered (gdb_stdlog,
+				"LNPAW: Received %s after attaching\n",
+				status_to_str (status));
+	}
     }
+  else
+    /* We could have been notified about LWP exit.  */
+    gdb_assert (*cloned);
 
   return status;
 }

Re: [patch] Fix for internal-error: linux_nat_post_attach_wait: Assertion `pid == new_pid && WIFSTOPPED (status)' failed.

[Pedro Alves]

On Tuesday 13 October 2009 19:41:20, Paul Pluzhnikov wrote:

> warning: Can't attach LWP 15338: No such process
> ../../src/gdb/linux-nat.c:1341: internal-error: linux_nat_post_attach_wait: Assertion `pid == new_pid && WIFSTOPPED (status)' failed.
> 
> When assertion fails, status == 0.
> 

> 
> 2009-10-13  Paul Pluzhnikov  <ppluzhnikov@google.com>
> 
> 	* linux-nat.c (linux_nat_post_attach_wait): Adjust assert.
> 
> 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	13 Oct 2009 18:18:37 -0000
> @@ -1338,16 +1338,22 @@ linux_nat_post_attach_wait (ptid_t ptid,
>        *cloned = 1;
>      }
>  
> -  gdb_assert (pid == new_pid && WIFSTOPPED (status));
> +  gdb_assert (pid == new_pid);
>  
> -  if (WSTOPSIG (status) != SIGSTOP)
> +  if (WIFSTOPPED (status))
>      {
> -      *signalled = 1;
> -      if (debug_linux_nat)
> -	fprintf_unfiltered (gdb_stdlog,
> -			    "LNPAW: Received %s after attaching\n",
> -			    status_to_str (status));
> +      if (WSTOPSIG (status) != SIGSTOP)
> +	{
> +	  *signalled = 1;
> +	  if (debug_linux_nat)
> +	    fprintf_unfiltered (gdb_stdlog,
> +				"LNPAW: Received %s after attaching\n",
> +				status_to_str (status));
> +	}
>      }
> +  else
> +    /* We could have been notified about LWP exit.  */
> +    gdb_assert (*cloned);
>  
>    return status;
>  }
> 

Sorry, but this isn't correct.  If you look at
linux_nat_post_attach_wait's callers, you'll see that they
assume that the LWP is stopped, but still alive.
E.g, note how lin_lwp_attach_lwp is using an unconditional
`WSTOPSIG (status)'.  The assertion guarded us into doing
such undefined things.  Without the assertion, we get
to handle the scenario.

The patch makes it so that we still leaves the already
gone LWP listed in the lwp list.  If you _don't_ issue an
"info threads" right after "attach", then, a "continue" will
make linux_nat_resume try to resume this already gone
thread along with the other alive lwps, which will
fail with a hard and confusing error.

So see this for yourself, try "attach; c" a few times, and
sometimes you won't see any problem, but other times you
should see errors.


Event if we assumed you'd not get that error on resume, if
the LWP happens to exit with any another exit code (or signalled),
linux_nat_post_attach_wait's callers would store that `status' as
a pending status (the lwp->status = status assignments).
This meant that "attach; c" would make linux_nat_wait_1 notice
the pending LWP exit event (pending events are handled before
going into waitpid to fetch more events), and this event would
be confused with a whole-process exit, and reported to infrun.c
as TARGET_WAITKIND_EXITED.  That is, a thread exit would
makes the core of GDB think the whole process exited.


I think what we should do is just get rid of the new
LWP that we found exiting right after attaching.  Pretend we
never saw it existed.  Pretend that we had attached to the
process just right after this LWP exited.


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).  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.

-- 
Pedro Alves

Re: [patch] Fix for internal-error: linux_nat_post_attach_wait: Assertion `pid == new_pid && WIFSTOPPED (status)' failed.

[Paul Pluzhnikov]

[-- 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.  */

Re: [patch] Fix for internal-error: linux_nat_post_attach_wait: Assertion `pid == new_pid && WIFSTOPPED (status)' failed.

[Pedro Alves]

On Wednesday 14 October 2009 19:21:03, Paul Pluzhnikov wrote:

> 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.

Ugh.  Happened much more often for me, like 1 in 5...

On Wednesday 14 October 2009 19:21:03, Paul Pluzhnikov wrote:
>  /* 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)
>  {

I don't think you needed the interface change.  The new interface
has two ways of saying the LWP exited, the 0 return, and
the !WIFSTOPPED(status), which looks strange.  With such an
interface, I would expect the return code to indicate a real failure,
but an exit indication isn't really a failure.  Any reason you'd not
just do ...

> -      status = linux_nat_post_attach_wait (ptid, 0, &cloned, &signalled);
> +      if (!linux_nat_post_attach_wait (ptid, 0, &status, &cloned, &signalled))
> +       return -1;
> +

      status = linux_nat_post_attach_wait (ptid, 0, &cloned, &signalled);
      if (!WIFSTOPPED (status))
        return -1;

?  Anyway, I was just surprised.  Either way is fine really.

> > 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.

Yes, it should.  Otherwise, the pending event is ignored (see
status_callback), and worse, in this case, you'll hit this
assertion:

linux_nat_wait_1:

  /* Make sure there is at least one LWP that has been resumed.  */
  gdb_assert (iterate_over_lwps (ptid, resumed_callback, NULL));


Oh, my bad.  I now took a look at what
infcmd.c:attach_command|attach_command_post_wait would do
in the case of the target_wait right after attach returning a
process exit, and it seems it would misbehave, and try to poke
at the inferior's memory...  Best not to go there for such a rare 
use case.  So, leaving the exit event pending ends up
fixing nothing afterall...

> 
> > 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.

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 ..."),
                     ...);

But if this looks too much trouble for what it's worth, that's
probably right :-).  I'd be quite fine to ignore that use case
for now.

-- 
Pedro Alves

Re: [patch] Fix for internal-error: linux_nat_post_attach_wait: Assertion `pid == new_pid && WIFSTOPPED (status)' failed.

[Paul Pluzhnikov]

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

On Wed, Oct 14, 2009 at 12:07 PM, Pedro Alves <pedro@codesourcery.com> 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.

> 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?

Anyway, here is try #3.

Thanks,
-- 
Paul Pluzhnikov

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

       * linux-nat.c (linux_nat_post_attach_wait): Adjust assert.
       (lin_lwp_attach_lwp, linux_nat_attach): Handle disappearing LWP.

[-- Attachment #2: gdb-assert-10757-20091014-2.txt --]
[-- Type: text/plain, Size: 2106 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 20:41:46 -0000
@@ -1338,7 +1338,16 @@ linux_nat_post_attach_wait (ptid_t ptid,
       *cloned = 1;
     }
 
-  gdb_assert (pid == new_pid && WIFSTOPPED (status));
+  gdb_assert (pid == new_pid);
+
+  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 status;
+    }
 
   if (WSTOPSIG (status) != SIGSTOP)
     {
@@ -1396,6 +1405,9 @@ lin_lwp_attach_lwp (ptid_t ptid)
 			    target_pid_to_str (ptid));
 
       status = linux_nat_post_attach_wait (ptid, 0, &cloned, &signalled);
+      if (!WIFSTOPPED (status))
+	return -1;
+
       lp = add_lwp (ptid);
       lp->stopped = 1;
       lp->cloned = cloned;
@@ -1495,6 +1507,37 @@ linux_nat_attach (struct target_ops *ops
 
   status = linux_nat_post_attach_wait (lp->ptid, 1, &lp->cloned,
 				       &lp->signalled);
+  if (!WIFSTOPPED (status))
+    {
+      delete_lwp (ptid);
+      if (WIFEXITED (status))
+	{
+	  int exit_code = WEXITSTATUS (status);
+
+	  target_terminal_ours ();
+	  target_mourn_inferior ();
+	  if (exit_code == 0)
+	    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."),
+		 target_signal_to_name (signo),
+		 target_signal_to_string (signo));
+	}
+
+      internal_error (__FILE__, __LINE__,
+		      _("unexpected status %d for PID %ld"),
+		      status, (long) GET_LWP (ptid));
+    }
+
   lp->stopped = 1;
 
   /* Save the wait status to report later.  */

Re: [patch] Fix for internal-error: linux_nat_post_attach_wait: Assertion `pid == new_pid && WIFSTOPPED (status)' failed.

[Pedro Alves]

On Wednesday 14 October 2009 22:01:05, Paul Pluzhnikov wrote:
> On Wed, Oct 14, 2009 at 12:07 PM, Pedro Alves <pedro@codesourcery.com> 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

Re: [patch] Fix for internal-error: linux_nat_post_attach_wait: Assertion `pid == new_pid && WIFSTOPPED (status)' failed.

[Paul Pluzhnikov]

On Wed, Oct 14, 2009 at 2:16 PM, Pedro Alves <pedro@codesourcery.com> wrote:

> I didn't mean to use those strings exactly. Please remove or replace
> "During startup" with something else. We're attaching, not starting up.

Oh, right. Sorry I missed that.

I am having a bit of trouble coming up with the right verbiage.
How about:

  error (_("Unable to attach: program exited normally."));

Alternatives:

  error (_("While attaching program exited normally."));
  error (_("During attach program exited normally."));

don't sound grammatically correct to me (and a comma is probably
missing from at least one of the above).

Thanks,
-- 
Paul Pluzhnikov

Re: [patch] Fix for internal-error: linux_nat_post_attach_wait: Assertion `pid == new_pid && WIFSTOPPED (status)' failed.

[Pedro Alves]

On Wednesday 14 October 2009 22:28:26, Paul Pluzhnikov wrote:
> I am having a bit of trouble coming up with the right verbiage.
> How about:
> 
>   error (_("Unable to attach: program exited normally."));
> 
> Alternatives:
> 
>   error (_("While attaching program exited normally."));
>   error (_("During attach program exited normally."));
> 
> don't sound grammatically correct to me (and a comma is probably
> missing from at least one of the above).

I've no preference really.  Any of those is fine with me.
If someone else wants to suggest something, I'm sure they'll
speak up now.  :-)

Something else I noticed:

> +         int signo = WTERMSIG (status);

Should be:

        enum target_signal signo = target_signal_from_host (WTERMSIG (status));

> +
> +         target_terminal_ours ();
> +         target_mourn_inferior ();
> +         error (_("During startup program terminated with signal %s, %s."),
> +                target_signal_to_name (signo),
> +                target_signal_to_string (signo));

                   ^^^^^^^^^^^^^^^^^^^^^^^

because these functions take a target independent gdb
signal (TARGET_SIGNAL_...).  Yes, it's confusing.

-- 
Pedro Alves

Re: [patch] Fix for internal-error: linux_nat_post_attach_wait: Assertion `pid == new_pid && WIFSTOPPED (status)' failed.

[Doug Evans]

On Wed, Oct 14, 2009 at 3:29 PM, Pedro Alves <pedro@codesourcery.com> wrote:
> Something else I noticed:
>
>> +         int signo = WTERMSIG (status);
>
> Should be:
>
>        enum target_signal signo = target_signal_from_host (WTERMSIG (status));
>
>> +
>> +         target_terminal_ours ();
>> +         target_mourn_inferior ();
>> +         error (_("During startup program terminated with signal %s, %s."),
>> +                target_signal_to_name (signo),
>> +                target_signal_to_string (signo));
>
>                   ^^^^^^^^^^^^^^^^^^^^^^^
>
> because these functions take a target independent gdb
> signal (TARGET_SIGNAL_...).  Yes, it's confusing.

These kinds of errors should be caught by the compilation system or language.
Then it wouldn't be confusing at all.

Re: [patch] Fix for internal-error: linux_nat_post_attach_wait: Assertion `pid == new_pid && WIFSTOPPED (status)' failed.

[Paul Pluzhnikov]

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

On Wed, Oct 14, 2009 at 3:29 PM, Pedro Alves <pedro@codesourcery.com> wrote:

> I've no preference really.  Any of those is fine with me.
> If someone else wants to suggest something, I'm sure they'll
> speak up now.  :-)

Nobody did, so I've checked in the "Unable to attach: ..." variant ...

> Something else I noticed:
...
> Should be:
>
>        enum target_signal signo = target_signal_from_host (WTERMSIG (status));

With that fix.

(Attached patch has been checked in, here just for reference.)

Thanks,
-- 
Paul Pluzhnikov

[-- Attachment #2: gdb-assert-10757-20091015.txt --]
[-- Type: text/plain, Size: 2152 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	15 Oct 2009 18:02:58 -0000
@@ -1338,7 +1338,16 @@ linux_nat_post_attach_wait (ptid_t ptid,
       *cloned = 1;
     }
 
-  gdb_assert (pid == new_pid && WIFSTOPPED (status));
+  gdb_assert (pid == new_pid);
+
+  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 status;
+    }
 
   if (WSTOPSIG (status) != SIGSTOP)
     {
@@ -1396,6 +1405,9 @@ lin_lwp_attach_lwp (ptid_t ptid)
 			    target_pid_to_str (ptid));
 
       status = linux_nat_post_attach_wait (ptid, 0, &cloned, &signalled);
+      if (!WIFSTOPPED (status))
+	return -1;
+
       lp = add_lwp (ptid);
       lp->stopped = 1;
       lp->cloned = cloned;
@@ -1495,6 +1507,39 @@ linux_nat_attach (struct target_ops *ops
 
   status = linux_nat_post_attach_wait (lp->ptid, 1, &lp->cloned,
 				       &lp->signalled);
+  if (!WIFSTOPPED (status))
+    {
+      if (WIFEXITED (status))
+	{
+	  int exit_code = WEXITSTATUS (status);
+
+	  target_terminal_ours ();
+	  target_mourn_inferior ();
+	  if (exit_code == 0)
+	    error (_("Unable to attach: program exited normally."));
+	  else
+	    error (_("Unable to attach: program exited with code %d."),
+		   exit_code);
+	}
+      else if (WIFSIGNALED (status))
+	{
+	  enum target_signal signo;
+
+	  target_terminal_ours ();
+	  target_mourn_inferior ();
+
+	  signo = target_signal_from_host (WTERMSIG (status));
+	  error (_("Unable to attach: program terminated with signal "
+		   "%s, %s."),
+		 target_signal_to_name (signo),
+		 target_signal_to_string (signo));
+	}
+
+      internal_error (__FILE__, __LINE__,
+		      _("unexpected status %d for PID %ld"),
+		      status, (long) GET_LWP (ptid));
+    }
+
   lp->stopped = 1;
 
   /* Save the wait status to report later.  */