This is the mail archive of the
gdb-testers@sourceware.org
mailing list for the GDB project.
[binutils-gdb] PR threads/18127 - threads spawned by infcall end up stuck in "running" state
- From: sergiodj+buildbot at redhat dot com
- To: gdb-testers at sourceware dot org
- Date: Mon, 29 Jun 2015 12:13:36 -0400
- Subject: [binutils-gdb] PR threads/18127 - threads spawned by infcall end up stuck in "running" state
- Authentication-results: sourceware.org; auth=none
*** TEST RESULTS FOR COMMIT 28bf096c62d7da6b349605f3940f4c586a850f78 ***
Author: Pedro Alves <palves@redhat.com>
Branch: master
Commit: 28bf096c62d7da6b349605f3940f4c586a850f78
PR threads/18127 - threads spawned by infcall end up stuck in "running" state
Refs:
https://sourceware.org/ml/gdb/2015-03/msg00024.html
https://sourceware.org/ml/gdb/2015-06/msg00005.html
On GNU/Linux, if an infcall spawns a thread, that thread ends up with
stuck running state. This happens because:
- when linux-nat.c detects a new thread, it marks them as running,
and does not report anything to the core.
- we skip finish_thread_state when the thread that is running the
infcall stops.
As result, that new thread ends up with stuck "running" state, even
though it really is stopped.
On Windows, _all_ threads end up stuck in running state, not just the
one that was spawned. That happens because when a new thread is
detected, unlike linux-nat.c, windows-nat.c reports
TARGET_WAITKIND_SPURIOUS to infrun. It's the fact that that event
does not cause a user-visible stop that triggers the problem. When
the target is re-resumed, we call set_running with a wildcard ptid,
which marks all thread as running. That set_running is not suppressed
because the (leader) thread being resumed does not have in_infcall
set. Later, when the infcall finally finishes successfully, nothing
marks all threads back to stopped.
We can trigger the same problem on all targets by having a thread
other than the one that is running the infcall report a breakpoint hit
to infrun, and then have that breakpoint not cause a stop. That's
what the included test does.
The fix is to stop GDB from suppressing the set_running calls while
doing an infcall, and then set the threads back to stopped when the
call finishes, iff they were originally stopped before the infcall
started. (Note the MI *running/*stopped event suppression isn't
affected.)
Tested on x86_64 GNU/Linux.
gdb/ChangeLog:
2015-06-29 Pedro Alves <palves@redhat.com>
PR threads/18127
* infcall.c (run_inferior_call): On infcall success, if the thread
was marked stopped before, reset it back to stopped.
* infrun.c (resume): Don't suppress the set_running calls when
doing an infcall.
(normal_stop): Only discard the finish_thread_state cleanup if the
infcall succeeded.
gdb/testsuite/ChangeLog:
2015-06-29 Pedro Alves <palves@redhat.com>
PR threads/18127
* gdb.threads/hand-call-new-thread.c: New file.
* gdb.threads/hand-call-new-thread.c: New file.
- Follow-Ups:
- Failures on Debian-s390x-native-extended-gdbserver-m64, branch master
- Failures on AIX-POWER7-plain, branch master
- Failures on Debian-i686, branch master
- Failures on Debian-s390x-m64, branch master
- Failures on Debian-s390x-native-gdbserver-m64, branch master
- Failures on Debian-i686-native-gdbserver, branch master
- Failures on Fedora-ppc64be-m64, branch master
- Failures on Fedora-ppc64le-native-extended-gdbserver-m64, branch master
- Failures on Fedora-x86_64-native-extended-gdbserver-m32, branch master
- Failures on Fedora-x86_64-cc-with-index, branch master
- Failures on Debian-i686-native-extended-gdbserver, branch master
- Failures on Fedora-ppc64be-native-extended-gdbserver-m64, branch master
- Failures on Fedora-x86_64-m64, branch master
- Failures on Fedora-x86_64-native-gdbserver-m32, branch master