aboutsummaryrefslogtreecommitdiff
path: root/gas
diff options
context:
space:
mode:
authorPedro Alves <palves@redhat.com>2016-01-25 12:00:20 +0000
committerPedro Alves <palves@redhat.com>2016-01-25 13:17:34 +0000
commita2077e254098828614ef6621cf8df28185e711d0 (patch)
tree16ccc40a7ee38ad7e7177b82d3a6027bb3591245 /gas
parent1d2736d43ba16c585e643faec4b6a5084d782289 (diff)
downloadgdb-a2077e254098828614ef6621cf8df28185e711d0.zip
gdb-a2077e254098828614ef6621cf8df28185e711d0.tar.gz
gdb-a2077e254098828614ef6621cf8df28185e711d0.tar.bz2
Fix PR 19461: strange "info thread" behavior in non-stop
If you have "set follow-fork child" set, then if you do "info threads" right after a fork, and before the child reports any other event to GDB core, you'll see: (gdb) info threads Id Target Id Frame * 1.1 Thread 0x7ffff7fc1740 (LWP 31875) "fork-plus-threa" (running) 2.1 process 31879 "fork-plus-threa" Selected thread is running. (gdb) The "Selected thread is running." bit is a bogus error. That was GDB trying to fetch the current frame of thread 2.1, because the external runnning state is "stopped", and then throwing an error because the thread is actually running. This actually affects all-stop + schedule-multiple as well. The problem here is that on a fork event, GDB doesn't update the external parent/child running states. New comprehensive test included. The "kill inferior 1" / "kill inferior 2" bits also trip on PR gdb/19494 (hang killing unfollowed fork children), which was fixed by the previous patch. gdb/ChangeLog: 2016-01-25 Pedro Alves <palves@redhat.com> PR threads/19461 * infrun.c (handle_inferior_event_1) <fork/vfork>: Update parent/child running states. gdb/testsuite/ChangeLog: 2016-01-25 Pedro Alves <palves@redhat.com> PR threads/19461 * gdb.base/fork-running-state.c: New file. * gdb.base/fork-running-state.exp: New file.
Diffstat (limited to 'gas')
0 files changed, 0 insertions, 0 deletions