public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
* [Bug cli/17828] New: [7.8 regression] -batch -ex r breaks terminal
@ 2015-01-11 20:31 jan.kratochvil at redhat dot com
  2015-01-12 16:55 ` [Bug cli/17828] " palves at redhat dot com
                   ` (4 more replies)
  0 siblings, 5 replies; 6+ messages in thread
From: jan.kratochvil at redhat dot com @ 2015-01-11 20:31 UTC (permalink / raw)
  To: gdb-prs

https://sourceware.org/bugzilla/show_bug.cgi?id=17828

            Bug ID: 17828
           Summary: [7.8 regression] -batch -ex r breaks terminal
           Product: gdb
           Version: 7.8
            Status: NEW
          Severity: normal
          Priority: P2
         Component: cli
          Assignee: unassigned at sourceware dot org
          Reporter: jan.kratochvil at redhat dot com
                CC: palves at redhat dot com
              Host: x86_64-linux-gnu
            Target: x86_64-linux-gnu

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.
$ _

-- 
You are receiving this mail because:
You are on the CC list for the bug.


^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug cli/17828] [7.8 regression] -batch -ex r breaks terminal
  2015-01-11 20:31 [Bug cli/17828] New: [7.8 regression] -batch -ex r breaks terminal jan.kratochvil at redhat dot com
@ 2015-01-12 16:55 ` palves at redhat dot com
  2015-01-14 12:37 ` cvs-commit at gcc dot gnu.org
                   ` (3 subsequent siblings)
  4 siblings, 0 replies; 6+ messages in thread
From: palves at redhat dot com @ 2015-01-12 16:55 UTC (permalink / raw)
  To: gdb-prs

https://sourceware.org/bugzilla/show_bug.cgi?id=17828

--- Comment #1 from Pedro Alves <palves at redhat dot com> ---
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

-- 
You are receiving this mail because:
You are on the CC list for the bug.


^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug cli/17828] [7.8 regression] -batch -ex r breaks terminal
  2015-01-11 20:31 [Bug cli/17828] New: [7.8 regression] -batch -ex r breaks terminal jan.kratochvil at redhat dot com
  2015-01-12 16:55 ` [Bug cli/17828] " palves at redhat dot com
@ 2015-01-14 12:37 ` cvs-commit at gcc dot gnu.org
  2015-01-14 12:43 ` cvs-commit at gcc dot gnu.org
                   ` (2 subsequent siblings)
  4 siblings, 0 replies; 6+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2015-01-14 12:37 UTC (permalink / raw)
  To: gdb-prs

https://sourceware.org/bugzilla/show_bug.cgi?id=17828

--- Comment #2 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug cli/17828] [7.8 regression] -batch -ex r breaks terminal
  2015-01-11 20:31 [Bug cli/17828] New: [7.8 regression] -batch -ex r breaks terminal jan.kratochvil at redhat dot com
  2015-01-12 16:55 ` [Bug cli/17828] " palves at redhat dot com
  2015-01-14 12:37 ` cvs-commit at gcc dot gnu.org
@ 2015-01-14 12:43 ` cvs-commit at gcc dot gnu.org
  2015-01-14 13:18 ` cvs-commit at gcc dot gnu.org
  2015-01-14 13:47 ` palves at redhat dot com
  4 siblings, 0 replies; 6+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2015-01-14 12:43 UTC (permalink / raw)
  To: gdb-prs

https://sourceware.org/bugzilla/show_bug.cgi?id=17828

--- Comment #3 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug cli/17828] [7.8 regression] -batch -ex r breaks terminal
  2015-01-11 20:31 [Bug cli/17828] New: [7.8 regression] -batch -ex r breaks terminal jan.kratochvil at redhat dot com
                   ` (2 preceding siblings ...)
  2015-01-14 12:43 ` cvs-commit at gcc dot gnu.org
@ 2015-01-14 13:18 ` cvs-commit at gcc dot gnu.org
  2015-01-14 13:47 ` palves at redhat dot com
  4 siblings, 0 replies; 6+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2015-01-14 13:18 UTC (permalink / raw)
  To: gdb-prs

https://sourceware.org/bugzilla/show_bug.cgi?id=17828

--- Comment #4 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug cli/17828] [7.8 regression] -batch -ex r breaks terminal
  2015-01-11 20:31 [Bug cli/17828] New: [7.8 regression] -batch -ex r breaks terminal jan.kratochvil at redhat dot com
                   ` (3 preceding siblings ...)
  2015-01-14 13:18 ` cvs-commit at gcc dot gnu.org
@ 2015-01-14 13:47 ` palves at redhat dot com
  4 siblings, 0 replies; 6+ messages in thread
From: palves at redhat dot com @ 2015-01-14 13:47 UTC (permalink / raw)
  To: gdb-prs

https://sourceware.org/bugzilla/show_bug.cgi?id=17828

Pedro Alves <palves at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #5 from Pedro Alves <palves at redhat dot com> ---
Fixed in 7.8, 7.9 and master.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2015-01-14 13:47 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-01-11 20:31 [Bug cli/17828] New: [7.8 regression] -batch -ex r breaks terminal jan.kratochvil at redhat dot com
2015-01-12 16:55 ` [Bug cli/17828] " palves at redhat dot com
2015-01-14 12:37 ` cvs-commit at gcc dot gnu.org
2015-01-14 12:43 ` cvs-commit at gcc dot gnu.org
2015-01-14 13:18 ` cvs-commit at gcc dot gnu.org
2015-01-14 13:47 ` palves at redhat dot com

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).