aboutsummaryrefslogtreecommitdiff
path: root/gdb/infrun.c
diff options
context:
space:
mode:
authorPedro Alves <palves@redhat.com>2015-03-24 14:24:53 +0000
committerPedro Alves <palves@redhat.com>2015-04-01 14:23:10 +0100
commit2ee52aa4283145a0f9417986b2f3d7f91e61b1b0 (patch)
tree5c9bfac06c6fc72900591231c1d4b2ec66b7b200 /gdb/infrun.c
parent3c724c8ca91ee8304ba355f681ccd906f0e9725b (diff)
downloadgdb-2ee52aa4283145a0f9417986b2f3d7f91e61b1b0.zip
gdb-2ee52aa4283145a0f9417986b2f3d7f91e61b1b0.tar.gz
gdb-2ee52aa4283145a0f9417986b2f3d7f91e61b1b0.tar.bz2
linux_nat.c: Mark new thread running even if momentarily pausing
My all-stop-on-top-of-non-stop series manages to trip on a bug in the linux-nat.c backend while running the testsuite. If a thread is discovered while threads are being momentarily paused (without the core's intervention), the thread ends up stuck in THREAD_STOPPED state, even though from the user's perspective, the thread is running even while it is paused. From inspection, in the current sources, this can happen if we call stop_and_resume_callback, though there's no way to test that with current Linux kernels. (While trying to come up with test to exercise this, I stumbled on: https://sourceware.org/ml/gdb-patches/2015-03/msg00850.html ... which does include a non-trivial test, so I think I can still claim I come out net positive. :-) ) Tested on x86_64 Fedora 20. gdb/ChangeLog: 2015-04-01 Pedro Alves <palves@redhat.com> * linux-nat.c (linux_handle_extended_wait): Always call set_running.
Diffstat (limited to 'gdb/infrun.c')
0 files changed, 0 insertions, 0 deletions