d3d4baedb6d247c6372678edd15195a1a93c2c6c is the first bad commit commit d3d4baedb6d247c6372678edd15195a1a93c2c6c Author: Pedro Alves <palves@redhat.com> Date: Thu Oct 23 17:13:35 2014 +0100 PR python/17372 - Python hangs when displaying help() $ echo 'main(){*(int*)0=0;}'|gcc -x c -;./gdb/gdb -batch -ex r ./a.out Program received signal SIGSEGV, Segmentation fault. 0x00000000004004ff in main () $ _ # Start typing next command - nothing happens - terminal is broken $ stty sane # Terminal gets fixed. $ _
Thanks Jan. I just sent a patch: [PATCH] [7.8 regression] PR cli/17828: -batch -ex r breaks terminal https://sourceware.org/ml/gdb-patches/2015-01/msg00299.html
The master branch has been updated by Pedro Alves <palves@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=6c400b59d574782afdb26eb6c021f28c31bb9f1c commit 6c400b59d574782afdb26eb6c021f28c31bb9f1c Author: Pedro Alves <palves@redhat.com> Date: Wed Jan 14 11:51:06 2015 +0000 PR cli/17828: -batch -ex r breaks terminal Commit d3d4baed (PR python/17372 - Python hangs when displaying help()) had the side effect of causing 'gdb -batch' to leave the terminal in the wrong state if the program was run. E.g,. $ echo 'main(){*(int*)0=0;}' | gcc -x c -; ./gdb/gdb -batch -ex r ./a.out Program received signal SIGSEGV, Segmentation fault. 0x00000000004004ff in main () $ If you start typing the next command, seemingly nothing happens - GDB left the terminal with echo disabled. The issue is that that "r" ends up in fetch_inferior_event, which calls reinstall_readline_callback_handler_cleanup, which causes readline to prep the terminal (raw, echo disabled). But "-batch" causes GDB to exit before the top level event loop is first started, and then nothing de-preps the terminal. The reinstall_readline_callback_handler_cleanup function's intro comment mentions: "Need to do this as we go back to the event loop, ready to process further input." but the implementation forgets the case of when the interpreter is sync, which indicates we won't return to the event loop yet, or as in the case of -batch, we have not started it yet. The fix is to not install the readline callback in that case. For the test, in this case, checking that command echo still works is sufficient. Comparing stty output before/after running GDB is even better. Because stty may not be available, the test tries both ways. In any case, since expect's spawn (what we use to start gdb) creates a new pseudo tty, another expect spawn or tcl exec after GDB exits would not see the wrong terminal settings. So instead, the test spawns a shell and runs stty and GDB in it. Tested on x86_64 Fedora 20. gdb/ 2015-01-14 Pedro Alves <palves@redhat.com> PR cli/17828 * infrun.c (reinstall_readline_callback_handler_cleanup): Don't reinstall if the interpreter is sync. gdb/testsuite/ 2015-01-14 Pedro Alves <palves@redhat.com> PR cli/17828 * gdb.base/batch-preserve-term-settings.c: New file. * gdb.base/batch-preserve-term-settings.exp: New file.
The gdb-7.9-branch branch has been updated by Pedro Alves <palves@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=d859384cf43fb33b0f3ca6cb25bbd5e325772851 commit d859384cf43fb33b0f3ca6cb25bbd5e325772851 Author: Pedro Alves <palves@redhat.com> Date: Wed Jan 14 12:38:47 2015 +0000 PR cli/17828: -batch -ex r breaks terminal Commit d3d4baed (PR python/17372 - Python hangs when displaying help()) had the side effect of causing 'gdb -batch' to leave the terminal in the wrong state if the program was run. E.g,. $ echo 'main(){*(int*)0=0;}' | gcc -x c -; ./gdb/gdb -batch -ex r ./a.out Program received signal SIGSEGV, Segmentation fault. 0x00000000004004ff in main () $ If you start typing the next command, seemingly nothing happens - GDB left the terminal with echo disabled. The issue is that that "r" ends up in fetch_inferior_event, which calls reinstall_readline_callback_handler_cleanup, which causes readline to prep the terminal (raw, echo disabled). But "-batch" causes GDB to exit before the top level event loop is first started, and then nothing de-preps the terminal. The reinstall_readline_callback_handler_cleanup function's intro comment mentions: "Need to do this as we go back to the event loop, ready to process further input." but the implementation forgets the case of when the interpreter is sync, which indicates we won't return to the event loop yet, or as in the case of -batch, we have not started it yet. The fix is to not install the readline callback in that case. For the test, in this case, checking that command echo still works is sufficient. Comparing stty output before/after running GDB is even better. Because stty may not be available, the test tries both ways. In any case, since expect's spawn (what we use to start gdb) creates a new pseudo tty, another expect spawn or tcl exec after GDB exits would not see the wrong terminal settings. So instead, the test spawns a shell and runs stty and GDB in it. Tested on x86_64 Fedora 20. gdb/ 2015-01-14 Pedro Alves <palves@redhat.com> PR cli/17828 * infrun.c (reinstall_readline_callback_handler_cleanup): Don't reinstall if the interpreter is sync. gdb/testsuite/ 2015-01-14 Pedro Alves <palves@redhat.com> PR cli/17828 * gdb.base/batch-preserve-term-settings.c: New file. * gdb.base/batch-preserve-term-settings.exp: New file.
The gdb-7.8-branch branch has been updated by Pedro Alves <palves@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=e6da5aefd46143872f59cb0d88c36a6fd55b2bf3 commit e6da5aefd46143872f59cb0d88c36a6fd55b2bf3 Author: Pedro Alves <palves@redhat.com> Date: Wed Jan 14 12:43:30 2015 +0000 PR cli/17828: -batch -ex r breaks terminal Commit d3d4baed (PR python/17372 - Python hangs when displaying help()) had the side effect of causing 'gdb -batch' to leave the terminal in the wrong state if the program was run. E.g,. $ echo 'main(){*(int*)0=0;}' | gcc -x c -; ./gdb/gdb -batch -ex r ./a.out Program received signal SIGSEGV, Segmentation fault. 0x00000000004004ff in main () $ If you start typing the next command, seemingly nothing happens - GDB left the terminal with echo disabled. The issue is that that "r" ends up in fetch_inferior_event, which calls reinstall_readline_callback_handler_cleanup, which causes readline to prep the terminal (raw, echo disabled). But "-batch" causes GDB to exit before the top level event loop is first started, and then nothing de-preps the terminal. The reinstall_readline_callback_handler_cleanup function's intro comment mentions: "Need to do this as we go back to the event loop, ready to process further input." but the implementation forgets the case of when the interpreter is sync, which indicates we won't return to the event loop yet, or as in the case of -batch, we have not started it yet. The fix is to not install the readline callback in that case. For the test, in this case, checking that command echo still works is sufficient. Comparing stty output before/after running GDB is even better. Because stty may not be available, the test tries both ways. In any case, since expect's spawn (what we use to start gdb) creates a new pseudo tty, another expect spawn or tcl exec after GDB exits would not see the wrong terminal settings. So instead, the test spawns a shell and runs stty and GDB in it. Tested on x86_64 Fedora 20. gdb/ 2015-01-14 Pedro Alves <palves@redhat.com> PR cli/17828 * infrun.c (reinstall_readline_callback_handler_cleanup): Don't reinstall if the interpreter is sync. gdb/testsuite/ 2015-01-14 Pedro Alves <palves@redhat.com> PR cli/17828 * gdb.base/batch-preserve-term-settings.c: New file. * gdb.base/batch-preserve-term-settings.exp: New file.
Fixed in 7.8, 7.9 and master.