aboutsummaryrefslogtreecommitdiff
path: root/depcomp
diff options
context:
space:
mode:
authorPedro Alves <palves@redhat.com>2014-07-09 17:52:58 +0100
committerPedro Alves <palves@redhat.com>2014-07-09 17:52:58 +0100
commit1fe2833b6dd03602ba86aa334e81466ea9abe66a (patch)
tree8520c25af7784886891634b1b86c9e93d47edc77 /depcomp
parent0318afefeff53becc1e3e738793ecdb6653629f4 (diff)
downloadgdb-upstream/gdb-7.8-branch.zip
gdb-upstream/gdb-7.8-branch.tar.gz
gdb-upstream/gdb-7.8-branch.tar.bz2
Fix "attach" command vs user input raceupstream/gdb-7.8-branch
On async targets, a synchronous attach is done like this: #1 - target_attach is called (PTRACE_ATTACH is issued) #2 - a continuation is installed #3 - we go back to the event loop #4 - target reports stop (SIGSTOP), event loop wakes up, and attach continuation is called #5 - among other things, the continuation calls target_terminal_inferior, which removes stdin from the event loop Note that in #3, GDB is still processing user input. If the user is fast enough, e.g., with something like: echo -e "attach PID\nset xxx=1" | gdb ... then the "set" command is processed before the attach completes. We get worse behavior even, if input is a tty and therefore readline/editing is enabled, with e.g.,: (gdb) attach PID\nset xxx=1 we then crash readline/gdb, with: Attaching to program: attach-wait-input, process 14537 readline: readline_callback_read_char() called with no handler! Aborted $ Fix this by calling target_terminal_inferior before #3 above. The test covers both scenarios by running with editing/readline forced to both on and off. gdb/ 2014-07-09 Pedro Alves <palves@redhat.com> * infcmd.c (attach_command_post_wait): Don't call target_terminal_inferior here. (attach_command): Call it here instead. gdb/testsuite/ 2014-07-09 Pedro Alves <palves@redhat.com> * gdb.base/attach-wait-input.exp: New file. * gdb.base/attach-wait-input.c: New file.
Diffstat (limited to 'depcomp')
0 files changed, 0 insertions, 0 deletions