diff options
author | Pedro Alves <palves@redhat.com> | 2014-07-09 17:52:58 +0100 |
---|---|---|
committer | Pedro Alves <palves@redhat.com> | 2014-07-09 17:52:58 +0100 |
commit | 1fe2833b6dd03602ba86aa334e81466ea9abe66a (patch) | |
tree | 8520c25af7784886891634b1b86c9e93d47edc77 /Install.in | |
parent | 0318afefeff53becc1e3e738793ecdb6653629f4 (diff) | |
download | gdb-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 'Install.in')
0 files changed, 0 insertions, 0 deletions