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. */
next prev parent 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