aboutsummaryrefslogtreecommitdiff
path: root/gdb/top.c
diff options
context:
space:
mode:
authorPedro Alves <palves@redhat.com>2016-09-06 23:29:25 +0100
committerPedro Alves <palves@redhat.com>2016-09-06 23:49:57 +0100
commit4295e285efa8193504ee08b9f633d9f8680bf181 (patch)
tree20c2160b9788a0b634123a58196af990ff7b6b16 /gdb/top.c
parenta025b477cc466112af0b120c5f2bf5d62a62017e (diff)
downloadfsf-binutils-gdb-4295e285efa8193504ee08b9f633d9f8680bf181.zip
fsf-binutils-gdb-4295e285efa8193504ee08b9f633d9f8680bf181.tar.gz
fsf-binutils-gdb-4295e285efa8193504ee08b9f633d9f8680bf181.tar.bz2
new-ui command: gdb internal errors if input is already pending
I noticed that if input is already pending on the new-ui TTY, gdb internal-errors. E.g., create /dev/pts/2, and type anything there (even just <return> is sufficient). Now start GDB creating a new UI on that TTY, while at the same time, running a synchronous execution command. Something like: $ gdb program -ex "new-ui console /dev/pts/2" -ex "start" Back on /dev/pts/2, we get: (gdb) .../src/gdb/event-top.c:360: internal-error: double prompt A problem internal to GDB has been detected, further debugging may prove unreliable. While the main UI was waiting for "start" to finish, gdb kepts pumping events, including the input fd of the extra console. The problem is that stdin_event_handler doesn't restore the current UI back to what it was, assuming that it's only ever called from the top level event loop. However, in this case, it's being called from the nested event loop from within maybe_wait_sync_command_done. When finally the "start" command is done, we reach the code that prints the prompt in the main UI, just before starting the main event loop. Since now the current UI is pointing at the extra console (by mistake), we find ourselves printing a double prompt on the extra console. This is caught by the assertion that fails, as shown above. Since other event handlers also don't restore the UI (e.g., signal event handlers), I think it's better if whatever is pumping events to take care to restore the UI, if it cares. That's what this patch does. New test included. gdb/ChangeLog: 2016-09-06 Pedro Alves <palves@redhat.com> * top.c (wait_sync_command_done): Don't assume current_ui doesn't change across events. Restore the current UI before returning. (gdb_readline_wrapper): Restore the current UI before returning. gdb/testsuite/ChangeLog: 2016-09-06 Pedro Alves <palves@redhat.com> * gdb.base/new-ui-pending-input.c: New file. * gdb.base/new-ui-pending-input.exp: New file. * gdb.exp (clear_gdb_spawn_id): New procedure. (with_spawn_id): Check whether gdb_spawn_id exists before referencing it. If gdb_spawn_id didn't exist on entry, clear it on exit.
Diffstat (limited to 'gdb/top.c')
-rw-r--r--gdb/top.c11
1 files changed, 10 insertions, 1 deletions
diff --git a/gdb/top.c b/gdb/top.c
index 5b385d2..320c296 100644
--- a/gdb/top.c
+++ b/gdb/top.c
@@ -561,9 +561,15 @@ check_frame_language_change (void)
void
wait_sync_command_done (void)
{
+ /* Processing events may change the current UI. */
+ struct cleanup *old_chain = make_cleanup_restore_current_ui ();
+ struct ui *ui = current_ui;
+
while (gdb_do_one_event () >= 0)
- if (current_ui->prompt_state != PROMPT_BLOCKED)
+ if (ui->prompt_state != PROMPT_BLOCKED)
break;
+
+ do_cleanups (old_chain);
}
/* See top.h. */
@@ -1030,6 +1036,9 @@ gdb_readline_wrapper (const char *prompt)
ui->secondary_prompt_depth++;
back_to = make_cleanup (gdb_readline_wrapper_cleanup, cleanup);
+ /* Processing events may change the current UI. */
+ make_cleanup_restore_current_ui ();
+
if (cleanup->target_is_async_orig)
target_async (0);