public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Don Breazeal <donb@codesourcery.com>
To: <gdb-patches@sourceware.org>, <palves@redhat.com>
Subject: [PATCH v2 1/3] PR remote/19496, internal err forking-threads-plus-bkpt
Date: Thu, 11 Feb 2016 00:26:00 -0000	[thread overview]
Message-ID: <1455150383-12456-1-git-send-email-donb@codesourcery.com> (raw)
In-Reply-To: <56AFC22A.8000007@redhat.com>

Hi Pedro,
Here is an update to the patch per your suggestion:

On 2/1/2016 12:38 PM, Pedro Alves wrote:
> On 01/28/2016 12:48 AM, Don Breazeal wrote:
>> This patch fixes an internal error that occurs in
>> gdb.threads/forking-threads-plus-breakpoint.exp:
>>
>> /blah/binutils-gdb/gdb/target.c:2723: internal-error: Can't determine the
>> current address space of thread Thread 3170.3170
>>
>> In default_thread_address_space, find_inferior_ptid couldn't find 3170.3170
>> because it had been overwritten in inferior_appeared,
---snip---
>> +static void
>> +update_thread_if_fork_parent (struct stop_reply *stop_reply)
>> +{
>> +  ptid_t ptid;
>> +
>> +  ptid = stop_reply->ptid;
>> +  if (stop_reply->ws.kind == TARGET_WAITKIND_FORKED
>> +      || stop_reply->ws.kind == TARGET_WAITKIND_VFORKED)
>> +    {
>> +      struct thread_info *tp = find_thread_ptid (ptid);
>> +
>> +      tp->pending_follow = stop_reply->ws;
>> +    }
>> +}
> 
> So the fork event has been reported out of target_wait but it was
> left pending on the infrun side (infrun.c:save_waitstatus)
> 
> IOW, the fork event hasn't been processed by handle_inferior_event
> yet, so it hasn't made it to tp->pending_follow yet.
> 
> The information is not lost, we're just looking for it in the
> wrong place.  I think this would be the right fix:

The fix below is essentially unchanged from your suggested fix.  The commit
message has been updated for the new fix.

Tested on Nios II Linux target with x86 Linux host, and native x86_64 Linux.

Thanks!
--Don

-----
This patch fixes an internal error that occurs in
gdb.threads/forking-threads-plus-breakpoint.exp:

/blah/binutils-gdb/gdb/target.c:2723: internal-error: Can't determine the
current address space of thread Thread 3170.3170

In default_thread_address_space, find_inferior_ptid couldn't find 3170.3170
because it had been overwritten in inferior_appeared, called as follows:

inferior_appeared
  remote_add_inferior
    remote_notice_new_inferior
      remote_update_thread_list

The cause of the problem was the following sequence of events:

* GDB knows only about the main thread

* the first fork event is reported to GDB, saved as pending_event

* qXfer:threads:read gets the threads from the remote.
  remove_new_fork_children id's the fork child from the pending event
  and removes it from the list reported to GDB.  All the rest of the
  threads, including the fork parent, are added to the GDB thread list.

* GDB stops all the threads.  All the stop events are pushed onto the
  stop reply queue behind the pending fork event.  The fork waitstatus
  is saved in the fork parent thread's pending status field
  thread_info.suspend.

* remote_wait_ns calls queued_stop_reply and process_stop_reply to
  remove the fork event from the front of the stop reply queue and save
  event information in the thread_info structure for the fork parent
  thread.  Unfortunately, none of the information saved in this way is
  the fork-specific information.

* A subsequent qXfer:threads:read packet gets the thread list including
  the fork parent and fork child.  remove_new_fork_children checks the
  thread list to see if there is a fork parent, doesn't find one, checks
  the stop reply queue for a pending fork event, doesn't find one, and
  allows the fork child thread to be reported to GDB before the fork
  event has been handled.  remote_update_thread_list calls
  remote_notice_new_thread and overwrites the current (main) thread in
  inferior_appeared.

So the fork event has been reported out of target_wait but it was left
pending on the infrun side (infrun.c:save_waitstatus).  IOW, the fork
event hasn't been processed by handle_inferior_event yet, so it hasn't
made it to tp->pending_follow yet.

The fix is to check thread_info.suspend along with the
thread_info.pending_follow in remote.c:remove_new_fork_children, to
prevent premature reporting of the fork child thread creation.

gdb/ChangeLog:
2016-02-10  Don Breazeal  <donb@codesourcery.com>

	PR remote/19496
	* remote.c (remove_new_fork_children): Check for pending
	fork status in thread_info.suspend.

gdb/testsuite/ChangeLog:
2016-02-10  Don Breazeal  <donb@codesourcery.com>

	PR remote/19496
	* gdb.threads/forking-threads-plus-breakpoint.exp (do_test):
	Remove kfail for PR remote/19496.

---
 gdb/remote.c                                                  | 7 ++++++-
 gdb/testsuite/gdb.threads/forking-threads-plus-breakpoint.exp | 6 ------
 2 files changed, 6 insertions(+), 7 deletions(-)

diff --git a/gdb/remote.c b/gdb/remote.c
index 6d56f19..f09a06e 100644
--- a/gdb/remote.c
+++ b/gdb/remote.c
@@ -6166,7 +6166,12 @@ remove_new_fork_children (struct threads_listing_context *context)
      fork child threads from the CONTEXT list.  */
   ALL_NON_EXITED_THREADS (thread)
     {
-      struct target_waitstatus *ws = &thread->pending_follow;
+      struct target_waitstatus *ws;
+
+      if (thread->suspend.waitstatus_pending_p)
+	ws = &thread->suspend.waitstatus;
+      else
+	ws = &thread->pending_follow;
 
       if (is_pending_fork_parent (ws, pid, thread->ptid))
 	{
diff --git a/gdb/testsuite/gdb.threads/forking-threads-plus-breakpoint.exp b/gdb/testsuite/gdb.threads/forking-threads-plus-breakpoint.exp
index 6c72061..ff3ca9a 100644
--- a/gdb/testsuite/gdb.threads/forking-threads-plus-breakpoint.exp
+++ b/gdb/testsuite/gdb.threads/forking-threads-plus-breakpoint.exp
@@ -100,12 +100,6 @@ proc do_test { cond_bp_target detach_on_fork displaced } {
     set fork_count 0
     set ok 0
 
-    if {$displaced == "off"
-	&& [target_info exists gdb_protocol]
-	&& ([target_info gdb_protocol] == "remote"
-	    || [target_info gdb_protocol] == "extended-remote")} {
-	setup_kfail "remote/19496" *-*-*
-    }
     set test "inferior 1 exited"
     gdb_test_multiple "" $test {
 	-re "Inferior 1 \(\[^\r\n\]+\) exited normally" {
-- 
1.8.1.1

  reply	other threads:[~2016-02-11  0:26 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-28  0:48 [PATCH 0/3] PR remote/19496, remote fork failures Don Breazeal
2016-01-28  0:48 ` [PATCH 3/3] PR remote/19496, timeout in forking-threads-plus-bkpt Don Breazeal
2016-02-01 12:05   ` Pedro Alves
2016-02-01 19:29     ` Don Breazeal
2016-02-01 20:09       ` Pedro Alves
2016-02-11  0:28         ` [PATCH v2 " Don Breazeal
2016-02-25 17:29           ` [PING]Re: " Don Breazeal
2016-03-03 18:20             ` [PING] " Don Breazeal
2016-03-14 21:30               ` Don Breazeal
2016-03-15 15:30           ` Pedro Alves
2016-03-16 17:29             ` Don Breazeal
2016-03-16 22:51               ` Don Breazeal
2016-03-17 10:38                 ` Pedro Alves
2016-02-11  0:28         ` [PATCH v2 2/3] PR remote/19496, interrupted syscall " Don Breazeal
2016-02-25 17:28           ` Don Breazeal
2016-03-03 18:19             ` [PING] " Don Breazeal
2016-03-14 21:29               ` Don Breazeal
2016-03-15 12:55           ` Pedro Alves
2016-03-16 18:26             ` Don Breazeal
2016-03-16 18:33               ` Pedro Alves
2016-03-16 22:18                 ` Don Breazeal
2016-01-28  0:48 ` [PATCH " Don Breazeal
2016-02-01 19:38   ` Pedro Alves
2016-01-28  0:48 ` [PATCH 1/3] PR remote/19496, internal err forking-threads-plus-bkpt Don Breazeal
2016-02-01 19:26   ` [pushed] Test gdb.threads/forking-threads-plus-breakpoint.exp with, displaced stepping off (Re: [PATCH 1/3] PR remote/19496, internal err forking-threads-plus-bkpt) Pedro Alves
2016-02-01 20:38   ` [PATCH 1/3] PR remote/19496, internal err forking-threads-plus-bkpt Pedro Alves
2016-02-11  0:26     ` Don Breazeal [this message]
2016-02-12 20:15       ` [PATCH v2 " Pedro Alves
2016-02-16 17:21         ` Don Breazeal

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=1455150383-12456-1-git-send-email-donb@codesourcery.com \
    --to=donb@codesourcery.com \
    --cc=gdb-patches@sourceware.org \
    --cc=palves@redhat.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).