public inbox for gdb-testers@sourceware.org help / color / mirror / Atom feed
From: sergiodj+buildbot@redhat.com To: gdb-testers@sourceware.org Subject: [binutils-gdb/gdb-7.11-branch] PR remote/19496, internal err forking-threads-plus-bkpt Date: Tue, 16 Feb 2016 17:31:00 -0000 [thread overview] Message-ID: <e993d610a980ea8df9200f158bfae69308c2138d@gdb-build> (raw) *** TEST RESULTS FOR COMMIT e993d610a980ea8df9200f158bfae69308c2138d *** Author: Don Breazeal <donb@codesourcery.com> Branch: gdb-7.11-branch Commit: e993d610a980ea8df9200f158bfae69308c2138d PR remote/19496, internal err forking-threads-plus-bkpt 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: PR remote/19496 * remote.c (remove_new_fork_children): Check for pending fork status in thread_info.suspend. gdb/testsuite/ChangeLog: PR remote/19496 * gdb.threads/forking-threads-plus-breakpoint.exp (do_test): Remove kfail for PR remote/19496.
next reply other threads:[~2016-02-16 17:31 UTC|newest] Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-02-16 17:31 sergiodj+buildbot [this message] 2016-02-16 17:31 ` Failures on RHEL-s390x-m64, branch gdb-7.11-branch sergiodj+buildbot 2016-02-16 17:34 ` Failures on Fedora-x86_64-m32, " sergiodj+buildbot 2016-02-16 17:47 ` Failures on Fedora-x86_64-native-gdbserver-m64, " sergiodj+buildbot 2016-02-16 17:47 ` Failures on Fedora-x86_64-native-extended-gdbserver-m64, " sergiodj+buildbot 2016-02-16 17:54 ` Failures on Fedora-x86_64-native-gdbserver-m32, " sergiodj+buildbot 2016-02-16 18:06 ` Failures on AIX-POWER7-plain, " sergiodj+buildbot 2016-02-16 19:42 ` Failures on Debian-s390x-native-gdbserver-m64, " sergiodj+buildbot 2016-02-16 20:32 ` Failures on Debian-s390x-native-extended-gdbserver-m64, " sergiodj+buildbot 2016-02-16 22:20 ` Failures on Debian-i686, " sergiodj+buildbot 2016-02-16 22:41 ` Failures on Debian-i686-native-gdbserver, " sergiodj+buildbot 2016-02-16 22:41 ` Failures on Fedora-ppc64be-cc-with-index, " sergiodj+buildbot 2016-02-16 23:08 ` Failures on Debian-i686-native-extended-gdbserver, " sergiodj+buildbot 2016-02-16 23:40 ` Failures on Fedora-ppc64be-native-extended-gdbserver-m64, " sergiodj+buildbot 2016-02-17 0:42 ` Failures on Fedora-ppc64le-native-extended-gdbserver-m64, " sergiodj+buildbot 2016-02-17 1:18 ` Failures on Fedora-ppc64le-native-gdbserver-m64, " sergiodj+buildbot 2016-02-17 3:07 ` Failures on Debian-x86_64-native-gdbserver-m64, " sergiodj+buildbot
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=e993d610a980ea8df9200f158bfae69308c2138d@gdb-build \ --to=sergiodj+buildbot@redhat.com \ --cc=gdb-testers@sourceware.org \ /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: linkBe 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).