Bug 17072 - Assertion `sync_execution || !target_can_async_p ()' failed.
Summary: Assertion `sync_execution || !target_can_async_p ()' failed.
Status: RESOLVED FIXED
Alias: None
Product: gdb
Classification: Unclassified
Component: gdb (show other bugs)
Version: HEAD
: P2 normal
Target Milestone: ---
Assignee: Pedro Alves
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-06-19 13:06 UTC by Jan Kratochvil
Modified: 2014-10-29 18:15 UTC (History)
1 user (show)

See Also:
Host: x86_64-linux-gnu
Target: x86_64-linux-gnu
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Kratochvil 2014-06-19 13:06:36 UTC
stty size
34 119
./gdb ./gdb -ex start -ex 'break *main' -ex 'break *main+1' -ex 'break *main+2' -ex 'break *main+3' -ex c
[...]
Type "apropos word" to search for commands related to "word".
(gdb) ---Type <return> to continue, or q <return> to quit---No unwaited-for children left.


Program received signal SIGINT, Interrupt.
infrun.c:6134: internal-error: normal_stop: Assertion `sync_execution || !target_can_async_p ()' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) _

After the inferior GDB prompt '(gdb) ' type CTRL-C and then type ENTER.
Comment 1 cvs-commit@gcc.gnu.org 2014-07-14 19:39:06 UTC
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "gdb and binutils".

The branch, master has been updated
       via  8258415802426fd3e6956cc8dc7aa093052177a5 (commit)
       via  1e9735707b34b8141ea3bfd88205ea26e99891fc (commit)
       via  93d6eb10ede1d8b72b274345c63f66439eaf7fd0 (commit)
       via  0017922d0292d8c374584f6100874580659c9973 (commit)
       via  94696ad31c3fac4a3bc17391e42362d83be1fb56 (commit)
       via  bd29394088b5685d336a501fadca88b25ed777bc (commit)
       via  9d1e69a21488cb5b8b7553c8df18ee5c3f4d82e3 (commit)
       via  feefc97b5942325a8b7793e7ae089d87ecdee11c (commit)
       via  c933f875f4416a2a06c14fb9e483dd888a948eb2 (commit)
      from  feb6f816c2246f29e1f71db11a757cbf99c25492 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=8258415802426fd3e6956cc8dc7aa093052177a5

commit 8258415802426fd3e6956cc8dc7aa093052177a5
Author: Pedro Alves <palves@redhat.com>
Date:   Mon Jul 14 19:55:32 2014 +0100

    Put GDB's terminal settings into effect when paginating
    
    When the target is resumed in the foreground, we put the inferior's
    terminal settings into effect, and remove stdin from the event loop.
    When the target stops, we put GDB's terminal settings into effect
    again, and re-register stdin in the event loop, ready for user input.
    The former is done by target_terminal_inferior, and the latter by
    target_terminal_ours.
    
    There's an intermediate -- target_terminal_ours_for_output -- that is
    called when printing output related to target events, and we don't
    know yet whether we'll stop the program.  That puts our terminal
    settings into effect, enough to get proper results from our output,
    but leaves input wired into the inferior.
    
    If such output paginates, then we need the full target_terminal_ours
    in order for the user to be able to provide input to answer the
    pagination query.
    
    The test in this commit hangs in async-capable targets without the fix
    (as the user/test can't answer the pagination query).  It doesn't hang
    on sync targets because on those we don't unregister stdin from the
    event loop while the target is running (because we block in
    target_wait instead of in the event loop in that case).
    
    gdb/
    2014-07-14  Pedro Alves  <palves@redhat.com>
    
    	* utils.c (prompt_for_continue): Call target_terminal_ours.
    
    gdb/testsuite/
    2014-07-14  Pedro Alves  <palves@redhat.com>
    
    	* gdb.base/paginate-after-ctrl-c-running.c: New file.
     	* gdb.base/paginate-after-ctrl-c-running.exp: New file.

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=1e9735707b34b8141ea3bfd88205ea26e99891fc

commit 1e9735707b34b8141ea3bfd88205ea26e99891fc
Author: Pedro Alves <palves@redhat.com>
Date:   Mon Jul 14 19:55:32 2014 +0100

    Fix double prompt
    
    If an error is thrown while handling a target event (within
    fetch_inferior_event), and, the interpreter is not async (but the
    target is), then GDB prints the prompt twice.
    
    One way to see that in action is throw a QUIT while in a pagination
    prompt issued from within fetch_inferior_event (or one of its
    callees).  E.g. from the test:
    
     ---Type <return> to continue, or q <return> to quit---
     ^CQuit
     (gdb) (gdb) p 1
     ^^^^^^^^^^^
     $1 = 1
     (gdb)
    
    The issue is that inferior_event_handler swallows errors and notifies
    the observers (the interpreters) about the command error, even if the
    interpreter is forced sync while we're handling a nested event loop
    (for execute_command).  The observers print a prompt, and then when we
    get back to the top event loop, we print another (in
    start_event_loop).
    
    I see no reason the error should be swallowed here.  Just cancel the
    execution related bits and let the error propagate to the top level
    (start_event_loop), which re-enables stdin and notifies observers.
    
    gdb/
    2014-07-14  Pedro Alves  <palves@redhat.com>
    
    	* inf-loop.c (inferior_event_handler): Use TRY_CATCH instead of
    	catch_errors.  Don't re-enable stdin or notify observers where,
    	and rethrow error.
    	(fetch_inferior_event_wrapper): Delete.
    
    gdb/testsuite/
    2014-07-14  Pedro Alves  <palves@redhat.com>
    
    	* gdb.base/double-prompt-target-event-error.c: New file.
    	* gdb.base/double-prompt-target-event-error.exp: New file.

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=93d6eb10ede1d8b72b274345c63f66439eaf7fd0

commit 93d6eb10ede1d8b72b274345c63f66439eaf7fd0
Author: Pedro Alves <palves@redhat.com>
Date:   Mon Jul 14 19:55:32 2014 +0100

    Remove the target from the event loop while in secondary prompts
    
    If a pagination prompt triggers while the target is running, and the
    target exits before the user responded to the pagination query, this
    happens:
    
      Starting program: foo
      ---Type <return> to continue, or q <return> to quit---No unwaited-for children left.
      Couldn't get registers: No such process.
      Couldn't get registers: No such process.
      Couldn't get registers: No such process.
      (gdb) Couldn't get registers: No such process.
      (gdb)
    
    To reiterate, the user hasn't replied to the pagination prompt above.
    
    A pagination query nests an event loop (in gdb_readline_wrapper).  In
    async mode, in addition to stdin and signal handlers, we'll have the
    target also installed in the event loop still.  So if the target
    reports an event, that wakes up the nested event loop, which calls
    into fetch_inferior_event etc. to handle the event which generates
    further output, all while we should be waiting for pagination
    confirmation...
    
    (TBC, any target event that generates output ends up spuriously waking
    up the pagination, though exits seem to be the worse kind.)
    
    I've played with a couple different approaches to fixing this, while
    at the same time trying to avoid being invasive.  Both revolve around
    not listening to target events while in a pagination prompt (doing
    anything else I think would be a much bigger change).
    
    The approach taken just removes the target from the event loop while
    within gdb_readline_wrapper.  The other approach used gdb_select
    directly, with only input_fd installed, but that had the issue that it
    didn't handle the async signal handlers, and turned out to be a bit
    more code than the first version.
    
    gdb/
    2014-07-14  Pedro Alves  <palves@redhat.com>
    
    	PR gdb/17072
    	* top.c: Include "inf-loop.h".
    	(struct gdb_readline_wrapper_cleanup) <target_is_async_orig>: New
    	field.
    	(gdb_readline_wrapper_cleanup): Make the target async again, if it
    	was async before.
    	(gdb_readline_wrapper): Store whether the target is async, and
    	make it sync.
    
    gdb/testsuite/
    2014-07-14  Pedro Alves  <palves@redhat.com>
    
    	PR gdb/17072
    	* gdb.base/paginate-inferior-exit.c: New file.
    	* gdb.base/paginate-inferior-exit.exp: New file.

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=0017922d0292d8c374584f6100874580659c9973

commit 0017922d0292d8c374584f6100874580659c9973
Author: Pedro Alves <palves@redhat.com>
Date:   Mon Jul 14 19:55:32 2014 +0100

    Background execution + pagination aborts readline/gdb
    
    If pagination occurs as result of output sent as response to a target
    event while the target is executing in the background, subsequent
    input aborts readline/gdb:
    
     $ gdb program
     ...
     (gdb) continue&
     Continuing.
     (gdb)
     ---Type <return> to continue, or q <return> to quit---
     *return*
     ---Type <return> to continue, or q <return> to quit---
     Breakpoint 2, after_sleep () at paginate-bg-execution.c:21
     ---Type <return> to continue, or q <return> to quit---
     21        return; /* after sleep */
     p 1
     readline: readline_callback_read_char() called with no handler!
     *abort/SIGABRT*
     $
    
    gdb_readline_wrapper_line removes the handler after a line is
    processed.  Usually, we'll end up re-displaying the prompt, and that
    reinstalls the handler.  But if the output is coming out of handling
    a stop event, we don't re-display the prompt, and nothing restores the
    handler.  So the next input wakes up the event loop and calls into
    readline, which aborts.
    
    We should do better with the prompt handling while the target is
    running (I think we should coordinate with readline, and
    hide/redisplay it around output), but that's a more invasive change
    better done post 7.8, so this patch is conservative and just
    reinstalls the handler as soon as we're out of the readline line
    callback.
    
    gdb/
    2014-07-14  Pedro Alves  <palves@redhat.com>
    
    	PR gdb/17072
    	* top.c (gdb_readline_wrapper_line): Tweak comment.
    	(gdb_readline_wrapper_cleanup): If readline is enabled, reinstall
    	the input handler callback.
    
    gdb/testsuite/
    2014-07-14  Pedro Alves  <palves@redhat.com>
    
    	PR gdb/17072
    	* gdb.base/paginate-bg-execution.c: New file.
    	* gdb.base/paginate-bg-execution.exp: New file.

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=94696ad31c3fac4a3bc17391e42362d83be1fb56

commit 94696ad31c3fac4a3bc17391e42362d83be1fb56
Author: Pedro Alves <palves@redhat.com>
Date:   Mon Jul 14 19:55:31 2014 +0100

    Canceling pagination caused by execution command from command line aborts readline/gdb
    
    This fixes:
    
     $ ./gdb program -ex "set height 2" -ex "start"
     ...
     Reading symbols from /home/pedro/gdb/tests/threads...done.
     ---Type <return> to continue, or q <return> to quit---^CQuit  << ctrl-c triggers a Quit
    
     *type something*
     readline: readline_callback_read_char() called with no handler!
     Aborted
     $
    
    Usually, if an error propagates all the way to the top level, we'll
    re-enable stdin, in case the command that was running was a
    synchronous command.  That's done in the event loop's actual loop
    (event-loop.c:start_event_loop).  However, if a foreground execution
    command is run before the event loop starts and throws, nothing is
    presently reenabling stdin, which leaves sync_execution set.
    
    When we do start the event loop, because sync_execution is still
    (mistakenly) set, display_gdb_prompt removes the readline input
    callback, even though stdin is registered in the event loop.  Any
    input from here on results in readline aborting.
    
    Such commands are run through catch_command_errors,
    catch_command_errors_const, so add the tweak there.
    
    gdb/
    2014-07-14  Pedro Alves  <palves@redhat.com>
    
    	PR gdb/17072
    	* main.c: Include event-top.h.
    	(handle_command_errors): New function.
    	(catch_command_errors, catch_command_errors_const): Use it.
    
    gdb/testsuite/
    2014-07-14  Pedro Alves  <palves@redhat.com>
    
    	PR gdb/17072
    	* gdb.base/paginate-execution-startup.c: New file.
    	* gdb.base/paginate-execution-startup.exp: New file.
    	* lib/gdb.exp (pagination_prompt): New global.
    	(default_gdb_spawn): New procedure, factored out from
    	default_gdb_spawn.
    	(default_gdb_start): Adjust to call default_gdb_spawn.
    	(gdb_spawn): New procedure.

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=bd29394088b5685d336a501fadca88b25ed777bc

commit bd29394088b5685d336a501fadca88b25ed777bc
Author: Pedro Alves <palves@redhat.com>
Date:   Mon Jul 14 19:55:31 2014 +0100

    testsuite: Introduce gdb_assert
    
    Often we'll do something like:
    
        if {$ok} {
    	fail "whatever"
        } else {
    	pass "whatever"
        }
    
    This adds a helper procedure for that, and converts one random place
    to use it, as an example.
    
    2014-07-14  Pedro Alves  <palves@redhat.com>
    
    	* lib/gdb.exp (gdb_assert): New procedure.
    	* gdb.trace/backtrace.exp (gdb_backtrace_tdp_4): Use it.

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=9d1e69a21488cb5b8b7553c8df18ee5c3f4d82e3

commit 9d1e69a21488cb5b8b7553c8df18ee5c3f4d82e3
Author: Pedro Alves <palves@redhat.com>
Date:   Mon Jul 14 19:55:31 2014 +0100

    Move catch_command_errors and catch_command_errors_const to main.c
    
    We'll need to add error handling code to commands run before the event
    loop starts (commands in .gdbinit, -ex commands, etc.).  Turns out
    those are run through catch_command_errors, and, catch_command_errors
    is used nowhere else.  Move it (and the _const variant) to main.c, so
    that we can further specialize it freely.
    
    gdb/
    2014-07-14  Pedro Alves  <palves@redhat.com>
    
    	* exceptions.c (catch_command_errors, catch_command_errors_const):
    	Moved to main.c.
    	* exceptions.h (catch_command_errors_ftype)
    	(catch_command_errors_const_ftype): Moved to main.c.
    	(catch_command_errors, catch_command_errors_const): Delete
    	declarations.
    	* main.c (catch_command_errors_ftype)
    	(catch_command_errors_const_ftype): Moved here from exceptions.h.
    	(catch_command_errors, catch_command_errors_const)): Moved here
    	from exceptions.c and make static.

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=feefc97b5942325a8b7793e7ae089d87ecdee11c

commit feefc97b5942325a8b7793e7ae089d87ecdee11c
Author: Pedro Alves <palves@redhat.com>
Date:   Mon Jul 14 19:55:30 2014 +0100

    Eliminate exceptions.c:print_any_exception.
    
    exception_print and exception_fprintf call print_flush, which does all the
    same flushing and annotation things that print_any_exception does, and more.
    
    gdb/
    2014-07-14  Pedro Alves  <palves@redhat.com>
    
    	* exceptions.c (print_any_exception): Delete.
    	(catch_exceptions_with_msg): Use exception_print instead of
    	print_any_exception.
    	(catch_errors): Use exception_fprintf instead of
    	print_any_exception.
    	(catch_command_errors, catch_command_errors_const): Use
    	exception_print instead of print_any_exception.

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=c933f875f4416a2a06c14fb9e483dd888a948eb2

commit c933f875f4416a2a06c14fb9e483dd888a948eb2
Author: Pedro Alves <palves@redhat.com>
Date:   Mon Jul 14 19:55:30 2014 +0100

    Put the inferior's terminal settings in effect while running (fg) infcalls
    
    The "call" and "print" commands presently always run synchronously, in
    the foreground, but GDB currently forgets to put the inferior's
    terminal settings into effect while running them, on async-capable
    targets, resulting in:
    
     (gdb) print func ()
     hello world
    
     Program received signal SIGTTOU, Stopped (tty output).
     0x000000373bceb8d0 in __libc_tcdrain (fd=1) at ../sysdeps/unix/sysv/linux/tcdrain.c:29
     29          return INLINE_SYSCALL (ioctl, 3, fd, TCSBRK, 1);
     The program being debugged was signaled while in a function called from GDB.
     GDB remains in the frame where the signal was received.
     To change this behavior use "set unwindonsignal on".
     Evaluation of the expression containing the function
     (func) will be abandoned.
     When the function is done executing, GDB will silently stop.
     (gdb)
    
    That's because target_terminal_inferior skips actually doing anything
    if running in the background, and, nothing is setting sync_execution
    while running infcalls:
    
     void
     target_terminal_inferior (void)
     {
       /* A background resume (``run&'') should leave GDB in control of the
          terminal.  Use target_can_async_p, not target_is_async_p, since at
          this point the target is not async yet.  However, if sync_execution
          is not set, we know it will become async prior to resume.  */
       if (target_can_async_p () && !sync_execution)
         return;
    
    This would best be all cleaned up by making GDB not even call
    target_terminal_inferior and try to pass the terminal to the inferior
    if running in the background, but that's a more invasive fix that is
    better done post-7.8.
    
    This was originally caught by a patch later in this series that makes
    catch_command_errors use exception_print instead of
    print_any_exception.  Note that print_flush calls serial_drain_output
    while print_any_exception doesnt't have that bit.  And,
    gdb.gdb/python-selftest.exp does:
    
     gdb_test "call catch_command_errors(execute_command, \"python print 5\", 0, RETURN_MASK_ALL)" \
       "Python not initialized.* = 0"
    
    which without this fix results in SIGTTOU...
    
    gdb/
    2014-07-14  Pedro Alves  <palves@redhat.com>
    
    	* infcall.c (run_inferior_call): Set 'sync_execution' while
    	running the inferior call.
    
    gdb/testsuite/
    2014-07-14  Pedro Alves  <palves@redhat.com>
    
    	* gdb.base/execution-termios.c: New file.
    	* gdb.base/execution-termios.exp: New file.

-----------------------------------------------------------------------

Summary of changes:
 gdb/ChangeLog                                      |   60 ++++++
 gdb/exceptions.c                                   |   54 +------
 gdb/exceptions.h                                   |   13 --
 gdb/inf-loop.c                                     |   36 ++--
 gdb/infcall.c                                      |    7 +
 gdb/main.c                                         |   58 ++++++
 gdb/testsuite/ChangeLog                            |   38 ++++
 .../gdb.base/double-prompt-target-event-error.c    |   25 +++
 .../gdb.base/double-prompt-target-event-error.exp  |  111 ++++++++++++
 gdb/testsuite/gdb.base/execution-termios.c         |   35 ++++
 gdb/testsuite/gdb.base/execution-termios.exp       |   60 ++++++
 .../gdb.base/paginate-after-ctrl-c-running.c       |   25 +++
 .../gdb.base/paginate-after-ctrl-c-running.exp     |   87 +++++++++
 gdb/testsuite/gdb.base/paginate-bg-execution.c     |   32 ++++
 gdb/testsuite/gdb.base/paginate-bg-execution.exp   |  127 +++++++++++++
 .../gdb.base/paginate-execution-startup.c          |   32 ++++
 .../gdb.base/paginate-execution-startup.exp        |  189 ++++++++++++++++++++
 gdb/testsuite/gdb.base/paginate-inferior-exit.c    |   32 ++++
 gdb/testsuite/gdb.base/paginate-inferior-exit.exp  |   85 +++++++++
 gdb/testsuite/gdb.trace/backtrace.exp              |    7 +-
 gdb/testsuite/lib/gdb.exp                          |   82 +++++++--
 gdb/top.c                                          |   21 ++-
 gdb/utils.c                                        |    4 +
 23 files changed, 1118 insertions(+), 102 deletions(-)
 create mode 100644 gdb/testsuite/gdb.base/double-prompt-target-event-error.c
 create mode 100644 gdb/testsuite/gdb.base/double-prompt-target-event-error.exp
 create mode 100644 gdb/testsuite/gdb.base/execution-termios.c
 create mode 100644 gdb/testsuite/gdb.base/execution-termios.exp
 create mode 100644 gdb/testsuite/gdb.base/paginate-after-ctrl-c-running.c
 create mode 100644 gdb/testsuite/gdb.base/paginate-after-ctrl-c-running.exp
 create mode 100644 gdb/testsuite/gdb.base/paginate-bg-execution.c
 create mode 100644 gdb/testsuite/gdb.base/paginate-bg-execution.exp
 create mode 100644 gdb/testsuite/gdb.base/paginate-execution-startup.c
 create mode 100644 gdb/testsuite/gdb.base/paginate-execution-startup.exp
 create mode 100644 gdb/testsuite/gdb.base/paginate-inferior-exit.c
 create mode 100644 gdb/testsuite/gdb.base/paginate-inferior-exit.exp
Comment 2 cvs-commit@gcc.gnu.org 2014-07-14 20:31:59 UTC
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "gdb and binutils".

The branch, gdb-7.8-branch has been updated
       via  06f304e861edd6faa92eb330e14116188d366819 (commit)
       via  49632fd86e34427e6b31cf7099acd83d8d85356e (commit)
       via  8ab3ff6a63e53bae0d5fbeb811d1368675dfa206 (commit)
       via  20b2168bed5192a15f86cb3e13cd60c5b1697a39 (commit)
       via  0181a2cfecc7254196074e029dd4be13c1a19347 (commit)
       via  8cad5e52ba2e9894e1f7efc692bf4b88de478aba (commit)
       via  46cbf2511331e43ed5ca03fce2e10158971b8b15 (commit)
       via  44c4124952bf5302253d43f66c89ec807790e692 (commit)
       via  c3bc697032b3637326e787c9ee1ccb79a18b0102 (commit)
      from  c086b11bd257f68392b75a2297d601a6ab741a6b (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=06f304e861edd6faa92eb330e14116188d366819

commit 06f304e861edd6faa92eb330e14116188d366819
Author: Pedro Alves <palves@redhat.com>
Date:   Mon Jul 14 20:43:51 2014 +0100

    Put GDB's terminal settings into effect when paginating
    
    When the target is resumed in the foreground, we put the inferior's
    terminal settings into effect, and remove stdin from the event loop.
    When the target stops, we put GDB's terminal settings into effect
    again, and re-register stdin in the event loop, ready for user input.
    The former is done by target_terminal_inferior, and the latter by
    target_terminal_ours.
    
    There's an intermediate -- target_terminal_ours_for_output -- that is
    called when printing output related to target events, and we don't
    know yet whether we'll stop the program.  That puts our terminal
    settings into effect, enough to get proper results from our output,
    but leaves input wired into the inferior.
    
    If such output paginates, then we need the full target_terminal_ours
    in order for the user to be able to provide input to answer the
    pagination query.
    
    The test in this commit hangs in async-capable targets without the fix
    (as the user/test can't answer the pagination query).  It doesn't hang
    on sync targets because on those we don't unregister stdin from the
    event loop while the target is running (because we block in
    target_wait instead of in the event loop in that case).
    
    gdb/
    2014-07-14  Pedro Alves  <palves@redhat.com>
    
    	* utils.c (prompt_for_continue): Call target_terminal_ours.
    
    gdb/testsuite/
    2014-07-14  Pedro Alves  <palves@redhat.com>
    
    	* gdb.base/paginate-after-ctrl-c-running.c: New file.
     	* gdb.base/paginate-after-ctrl-c-running.exp: New file.

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=49632fd86e34427e6b31cf7099acd83d8d85356e

commit 49632fd86e34427e6b31cf7099acd83d8d85356e
Author: Pedro Alves <palves@redhat.com>
Date:   Mon Jul 14 19:55:32 2014 +0100

    Fix double prompt
    
    If an error is thrown while handling a target event (within
    fetch_inferior_event), and, the interpreter is not async (but the
    target is), then GDB prints the prompt twice.
    
    One way to see that in action is throw a QUIT while in a pagination
    prompt issued from within fetch_inferior_event (or one of its
    callees).  E.g. from the test:
    
     ---Type <return> to continue, or q <return> to quit---
     ^CQuit
     (gdb) (gdb) p 1
     ^^^^^^^^^^^
     $1 = 1
     (gdb)
    
    The issue is that inferior_event_handler swallows errors and notifies
    the observers (the interpreters) about the command error, even if the
    interpreter is forced sync while we're handling a nested event loop
    (for execute_command).  The observers print a prompt, and then when we
    get back to the top event loop, we print another (in
    start_event_loop).
    
    I see no reason the error should be swallowed here.  Just cancel the
    execution related bits and let the error propagate to the top level
    (start_event_loop), which re-enables stdin and notifies observers.
    
    gdb/
    2014-07-14  Pedro Alves  <palves@redhat.com>
    
    	* inf-loop.c (inferior_event_handler): Use TRY_CATCH instead of
    	catch_errors.  Don't re-enable stdin or notify observers where,
    	and rethrow error.
    	(fetch_inferior_event_wrapper): Delete.
    
    gdb/testsuite/
    2014-07-14  Pedro Alves  <palves@redhat.com>
    
    	* gdb.base/double-prompt-target-event-error.c: New file.
    	* gdb.base/double-prompt-target-event-error.exp: New file.

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=8ab3ff6a63e53bae0d5fbeb811d1368675dfa206

commit 8ab3ff6a63e53bae0d5fbeb811d1368675dfa206
Author: Pedro Alves <palves@redhat.com>
Date:   Mon Jul 14 19:55:32 2014 +0100

    Remove the target from the event loop while in secondary prompts
    
    If a pagination prompt triggers while the target is running, and the
    target exits before the user responded to the pagination query, this
    happens:
    
      Starting program: foo
      ---Type <return> to continue, or q <return> to quit---No unwaited-for children left.
      Couldn't get registers: No such process.
      Couldn't get registers: No such process.
      Couldn't get registers: No such process.
      (gdb) Couldn't get registers: No such process.
      (gdb)
    
    To reiterate, the user hasn't replied to the pagination prompt above.
    
    A pagination query nests an event loop (in gdb_readline_wrapper).  In
    async mode, in addition to stdin and signal handlers, we'll have the
    target also installed in the event loop still.  So if the target
    reports an event, that wakes up the nested event loop, which calls
    into fetch_inferior_event etc. to handle the event which generates
    further output, all while we should be waiting for pagination
    confirmation...
    
    (TBC, any target event that generates output ends up spuriously waking
    up the pagination, though exits seem to be the worse kind.)
    
    I've played with a couple different approaches to fixing this, while
    at the same time trying to avoid being invasive.  Both revolve around
    not listening to target events while in a pagination prompt (doing
    anything else I think would be a much bigger change).
    
    The approach taken just removes the target from the event loop while
    within gdb_readline_wrapper.  The other approach used gdb_select
    directly, with only input_fd installed, but that had the issue that it
    didn't handle the async signal handlers, and turned out to be a bit
    more code than the first version.
    
    gdb/
    2014-07-14  Pedro Alves  <palves@redhat.com>
    
    	PR gdb/17072
    	* top.c: Include "inf-loop.h".
    	(struct gdb_readline_wrapper_cleanup) <target_is_async_orig>: New
    	field.
    	(gdb_readline_wrapper_cleanup): Make the target async again, if it
    	was async before.
    	(gdb_readline_wrapper): Store whether the target is async, and
    	make it sync.
    
    gdb/testsuite/
    2014-07-14  Pedro Alves  <palves@redhat.com>
    
    	PR gdb/17072
    	* gdb.base/paginate-inferior-exit.c: New file.
    	* gdb.base/paginate-inferior-exit.exp: New file.

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=20b2168bed5192a15f86cb3e13cd60c5b1697a39

commit 20b2168bed5192a15f86cb3e13cd60c5b1697a39
Author: Pedro Alves <palves@redhat.com>
Date:   Mon Jul 14 19:55:32 2014 +0100

    Background execution + pagination aborts readline/gdb
    
    If pagination occurs as result of output sent as response to a target
    event while the target is executing in the background, subsequent
    input aborts readline/gdb:
    
     $ gdb program
     ...
     (gdb) continue&
     Continuing.
     (gdb)
     ---Type <return> to continue, or q <return> to quit---
     *return*
     ---Type <return> to continue, or q <return> to quit---
     Breakpoint 2, after_sleep () at paginate-bg-execution.c:21
     ---Type <return> to continue, or q <return> to quit---
     21        return; /* after sleep */
     p 1
     readline: readline_callback_read_char() called with no handler!
     *abort/SIGABRT*
     $
    
    gdb_readline_wrapper_line removes the handler after a line is
    processed.  Usually, we'll end up re-displaying the prompt, and that
    reinstalls the handler.  But if the output is coming out of handling
    a stop event, we don't re-display the prompt, and nothing restores the
    handler.  So the next input wakes up the event loop and calls into
    readline, which aborts.
    
    We should do better with the prompt handling while the target is
    running (I think we should coordinate with readline, and
    hide/redisplay it around output), but that's a more invasive change
    better done post 7.8, so this patch is conservative and just
    reinstalls the handler as soon as we're out of the readline line
    callback.
    
    gdb/
    2014-07-14  Pedro Alves  <palves@redhat.com>
    
    	PR gdb/17072
    	* top.c (gdb_readline_wrapper_line): Tweak comment.
    	(gdb_readline_wrapper_cleanup): If readline is enabled, reinstall
    	the input handler callback.
    
    gdb/testsuite/
    2014-07-14  Pedro Alves  <palves@redhat.com>
    
    	PR gdb/17072
    	* gdb.base/paginate-bg-execution.c: New file.
    	* gdb.base/paginate-bg-execution.exp: New file.

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=0181a2cfecc7254196074e029dd4be13c1a19347

commit 0181a2cfecc7254196074e029dd4be13c1a19347
Author: Pedro Alves <palves@redhat.com>
Date:   Mon Jul 14 20:45:14 2014 +0100

    Canceling pagination caused by execution command from command line aborts readline/gdb
    
    This fixes:
    
     $ ./gdb program -ex "set height 2" -ex "start"
     ...
     Reading symbols from /home/pedro/gdb/tests/threads...done.
     ---Type <return> to continue, or q <return> to quit---^CQuit  << ctrl-c triggers a Quit
    
     *type something*
     readline: readline_callback_read_char() called with no handler!
     Aborted
     $
    
    Usually, if an error propagates all the way to the top level, we'll
    re-enable stdin, in case the command that was running was a
    synchronous command.  That's done in the event loop's actual loop
    (event-loop.c:start_event_loop).  However, if a foreground execution
    command is run before the event loop starts and throws, nothing is
    presently reenabling stdin, which leaves sync_execution set.
    
    When we do start the event loop, because sync_execution is still
    (mistakenly) set, display_gdb_prompt removes the readline input
    callback, even though stdin is registered in the event loop.  Any
    input from here on results in readline aborting.
    
    Such commands are run through catch_command_errors,
    catch_command_errors_const, so add the tweak there.
    
    gdb/
    2014-07-14  Pedro Alves  <palves@redhat.com>
    
    	PR gdb/17072
    	* main.c: Include event-top.h.
    	(handle_command_errors): New function.
    	(catch_command_errors, catch_command_errors_const): Use it.
    
    gdb/testsuite/
    2014-07-14  Pedro Alves  <palves@redhat.com>
    
    	PR gdb/17072
    	* gdb.base/paginate-execution-startup.c: New file.
    	* gdb.base/paginate-execution-startup.exp: New file.
    	* lib/gdb.exp (pagination_prompt): New global.
    	(default_gdb_spawn): New procedure, factored out from
    	default_gdb_spawn.
    	(default_gdb_start): Adjust to call default_gdb_spawn.
    	(gdb_spawn): New procedure.

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=8cad5e52ba2e9894e1f7efc692bf4b88de478aba

commit 8cad5e52ba2e9894e1f7efc692bf4b88de478aba
Author: Pedro Alves <palves@redhat.com>
Date:   Mon Jul 14 20:45:14 2014 +0100

    testsuite: Introduce gdb_assert
    
    Often we'll do something like:
    
        if {$ok} {
    	fail "whatever"
        } else {
    	pass "whatever"
        }
    
    This adds a helper procedure for that, and converts one random place
    to use it, as an example.
    
    2014-07-14  Pedro Alves  <palves@redhat.com>
    
    	* lib/gdb.exp (gdb_assert): New procedure.
    	* gdb.trace/backtrace.exp (gdb_backtrace_tdp_4): Use it.

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=46cbf2511331e43ed5ca03fce2e10158971b8b15

commit 46cbf2511331e43ed5ca03fce2e10158971b8b15
Author: Pedro Alves <palves@redhat.com>
Date:   Mon Jul 14 20:45:14 2014 +0100

    Move catch_command_errors and catch_command_errors_const to main.c
    
    We'll need to add error handling code to commands run before the event
    loop starts (commands in .gdbinit, -ex commands, etc.).  Turns out
    those are run through catch_command_errors, and, catch_command_errors
    is used nowhere else.  Move it (and the _const variant) to main.c, so
    that we can further specialize it freely.
    
    gdb/
    2014-07-14  Pedro Alves  <palves@redhat.com>
    
    	* exceptions.c (catch_command_errors, catch_command_errors_const):
    	Moved to main.c.
    	* exceptions.h (catch_command_errors_ftype)
    	(catch_command_errors_const_ftype): Moved to main.c.
    	(catch_command_errors, catch_command_errors_const): Delete
    	declarations.
    	* main.c (catch_command_errors_ftype)
    	(catch_command_errors_const_ftype): Moved here from exceptions.h.
    	(catch_command_errors, catch_command_errors_const)): Moved here
    	from exceptions.c and make static.

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=44c4124952bf5302253d43f66c89ec807790e692

commit 44c4124952bf5302253d43f66c89ec807790e692
Author: Pedro Alves <palves@redhat.com>
Date:   Mon Jul 14 20:45:13 2014 +0100

    Eliminate exceptions.c:print_any_exception.
    
    exception_print and exception_fprintf call print_flush, which does all the
    same flushing and annotation things that print_any_exception does, and more.
    
    gdb/
    2014-07-14  Pedro Alves  <palves@redhat.com>
    
    	* exceptions.c (print_any_exception): Delete.
    	(catch_exceptions_with_msg): Use exception_print instead of
    	print_any_exception.
    	(catch_errors): Use exception_fprintf instead of
    	print_any_exception.
    	(catch_command_errors, catch_command_errors_const): Use
    	exception_print instead of print_any_exception.

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=c3bc697032b3637326e787c9ee1ccb79a18b0102

commit c3bc697032b3637326e787c9ee1ccb79a18b0102
Author: Pedro Alves <palves@redhat.com>
Date:   Mon Jul 14 20:45:13 2014 +0100

    Put the inferior's terminal settings in effect while running (fg) infcalls
    
    The "call" and "print" commands presently always run synchronously, in
    the foreground, but GDB currently forgets to put the inferior's
    terminal settings into effect while running them, on async-capable
    targets, resulting in:
    
     (gdb) print func ()
     hello world
    
     Program received signal SIGTTOU, Stopped (tty output).
     0x000000373bceb8d0 in __libc_tcdrain (fd=1) at ../sysdeps/unix/sysv/linux/tcdrain.c:29
     29          return INLINE_SYSCALL (ioctl, 3, fd, TCSBRK, 1);
     The program being debugged was signaled while in a function called from GDB.
     GDB remains in the frame where the signal was received.
     To change this behavior use "set unwindonsignal on".
     Evaluation of the expression containing the function
     (func) will be abandoned.
     When the function is done executing, GDB will silently stop.
     (gdb)
    
    That's because target_terminal_inferior skips actually doing anything
    if running in the background, and, nothing is setting sync_execution
    while running infcalls:
    
     void
     target_terminal_inferior (void)
     {
       /* A background resume (``run&'') should leave GDB in control of the
          terminal.  Use target_can_async_p, not target_is_async_p, since at
          this point the target is not async yet.  However, if sync_execution
          is not set, we know it will become async prior to resume.  */
       if (target_can_async_p () && !sync_execution)
         return;
    
    This would best be all cleaned up by making GDB not even call
    target_terminal_inferior and try to pass the terminal to the inferior
    if running in the background, but that's a more invasive fix that is
    better done post-7.8.
    
    This was originally caught by a patch later in this series that makes
    catch_command_errors use exception_print instead of
    print_any_exception.  Note that print_flush calls serial_drain_output
    while print_any_exception doesnt't have that bit.  And,
    gdb.gdb/python-selftest.exp does:
    
     gdb_test "call catch_command_errors(execute_command, \"python print 5\", 0, RETURN_MASK_ALL)" \
       "Python not initialized.* = 0"
    
    which without this fix results in SIGTTOU...
    
    gdb/
    2014-07-14  Pedro Alves  <palves@redhat.com>
    
    	* infcall.c (run_inferior_call): Set 'sync_execution' while
    	running the inferior call.
    
    gdb/testsuite/
    2014-07-14  Pedro Alves  <palves@redhat.com>
    
    	* gdb.base/execution-termios.c: New file.
    	* gdb.base/execution-termios.exp: New file.

-----------------------------------------------------------------------

Summary of changes:
 gdb/ChangeLog                                      |   64 +++++++
 gdb/exceptions.c                                   |   54 +------
 gdb/exceptions.h                                   |   13 --
 gdb/inf-loop.c                                     |   36 ++--
 gdb/infcall.c                                      |    7 +
 gdb/main.c                                         |   58 ++++++
 gdb/testsuite/ChangeLog                            |   43 +++++
 .../gdb.base/double-prompt-target-event-error.c    |   25 +++
 .../gdb.base/double-prompt-target-event-error.exp  |  111 ++++++++++++
 gdb/testsuite/gdb.base/execution-termios.c         |   35 ++++
 gdb/testsuite/gdb.base/execution-termios.exp       |   60 ++++++
 .../gdb.base/paginate-after-ctrl-c-running.c       |   25 +++
 .../gdb.base/paginate-after-ctrl-c-running.exp     |   87 +++++++++
 gdb/testsuite/gdb.base/paginate-bg-execution.c     |   32 ++++
 gdb/testsuite/gdb.base/paginate-bg-execution.exp   |  127 +++++++++++++
 .../gdb.base/paginate-execution-startup.c          |   32 ++++
 .../gdb.base/paginate-execution-startup.exp        |  189 ++++++++++++++++++++
 gdb/testsuite/gdb.base/paginate-inferior-exit.c    |   32 ++++
 gdb/testsuite/gdb.base/paginate-inferior-exit.exp  |   85 +++++++++
 gdb/testsuite/gdb.trace/backtrace.exp              |    7 +-
 gdb/testsuite/lib/gdb.exp                          |   82 +++++++--
 gdb/top.c                                          |   21 ++-
 gdb/utils.c                                        |    4 +
 23 files changed, 1127 insertions(+), 102 deletions(-)
 create mode 100644 gdb/testsuite/gdb.base/double-prompt-target-event-error.c
 create mode 100644 gdb/testsuite/gdb.base/double-prompt-target-event-error.exp
 create mode 100644 gdb/testsuite/gdb.base/execution-termios.c
 create mode 100644 gdb/testsuite/gdb.base/execution-termios.exp
 create mode 100644 gdb/testsuite/gdb.base/paginate-after-ctrl-c-running.c
 create mode 100644 gdb/testsuite/gdb.base/paginate-after-ctrl-c-running.exp
 create mode 100644 gdb/testsuite/gdb.base/paginate-bg-execution.c
 create mode 100644 gdb/testsuite/gdb.base/paginate-bg-execution.exp
 create mode 100644 gdb/testsuite/gdb.base/paginate-execution-startup.c
 create mode 100644 gdb/testsuite/gdb.base/paginate-execution-startup.exp
 create mode 100644 gdb/testsuite/gdb.base/paginate-inferior-exit.c
 create mode 100644 gdb/testsuite/gdb.base/paginate-inferior-exit.exp
Comment 3 Pedro Alves 2014-07-14 20:39:39 UTC
Fixed.
Comment 4 cvs-commit@gcc.gnu.org 2014-10-29 17:33:43 UTC
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "gdb and binutils".

The branch, master has been updated
       via  d3d4baedb6d247c6372678edd15195a1a93c2c6c (commit)
      from  d1e8523e40ed5094ed7d5b352ac6b0eabf9f690c (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=d3d4baedb6d247c6372678edd15195a1a93c2c6c

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()
    
    This is more of a readline/terminal issue than a Python one.
    
    PR17372 is a regression in 7.8 caused by the fix for PR17072:
    
     commit 0017922d0292d8c374584f6100874580659c9973
     Author: Pedro Alves <palves@redhat.com>
     Date:   Mon Jul 14 19:55:32 2014 +0100
    
        Background execution + pagination aborts readline/gdb
    
        gdb_readline_wrapper_line removes the handler after a line is
        processed.  Usually, we'll end up re-displaying the prompt, and that
        reinstalls the handler.  But if the output is coming out of handling
        a stop event, we don't re-display the prompt, and nothing restores the
        handler.  So the next input wakes up the event loop and calls into
        readline, which aborts.
    ...
        gdb/
        2014-07-14  Pedro Alves  <palves@redhat.com>
    
            PR gdb/17072
            * top.c (gdb_readline_wrapper_line): Tweak comment.
            (gdb_readline_wrapper_cleanup): If readline is enabled, reinstall
            the input handler callback.
    
    The problem is that installing the input handler callback also preps
    the terminal, putting it in raw mode and with echo disabled, which is
    bad if we're going to call a command that assumes cooked/canonical
    mode, and echo enabled, like in the case of the PR, Python's
    interactive shell.  Another example I came up with that doesn't depend
    on Python is starting a subshell with "(gdb) shell /bin/sh" from a
    multi-line command.  Tests covering both these examples are added.
    
    The fix is to revert the original fix for PR gdb/17072, and instead
    restore the callback handler after processing an asynchronous target
    event.
    
    Furthermore, calling rl_callback_handler_install when we already have
    some input in readline's line buffer discards that input, which is
    obviously a bad thing to do while the user is typing.  No specific
    test is added for that, because I first tried calling it even if the
    callback handler was still installed and that resulted in hundreds of
    failures in the testsuite.
    
    gdb/
    2014-10-29  Pedro Alves  <palves@redhat.com>
    
    	PR python/17372
    	* event-top.c (change_line_handler): Call
    	gdb_rl_callback_handler_remove instead of
    	rl_callback_handler_remove.
    	(callback_handler_installed): New global.
    	(gdb_rl_callback_handler_remove, gdb_rl_callback_handler_install)
    	(gdb_rl_callback_handler_reinstall): New functions.
    	(display_gdb_prompt): Call gdb_rl_callback_handler_remove and
    	gdb_rl_callback_handler_install instead of
    	rl_callback_handler_remove and rl_callback_handler_install.
    	(gdb_disable_readline): Call gdb_rl_callback_handler_remove
    	instead of rl_callback_handler_remove.
    	* event-top.h (gdb_rl_callback_handler_remove)
    	(gdb_rl_callback_handler_install)
    	(gdb_rl_callback_handler_reinstall): New declarations.
    	* infrun.c (reinstall_readline_callback_handler_cleanup): New
    	cleanup function.
    	(fetch_inferior_event): Install it.
    	* top.c (gdb_readline_wrapper_line) Call
    	gdb_rl_callback_handler_remove instead of
    	rl_callback_handler_remove.
    	(gdb_readline_wrapper_cleanup): Don't call
    	rl_callback_handler_install.
    
    gdb/testsuite/
    2014-10-29  Pedro Alves  <palves@redhat.com>
    
    	PR python/17372
    	* gdb.python/python.exp: Test a multi-line command that spawns
    	interactive Python.
    	* gdb.base/multi-line-starts-subshell.exp: New file.

-----------------------------------------------------------------------

Summary of changes:
 gdb/ChangeLog                                      |   26 ++++++++
 gdb/event-top.c                                    |   61 ++++++++++++++++++--
 gdb/event-top.h                                    |   11 ++++
 gdb/infrun.c                                       |   20 +++++++
 gdb/testsuite/ChangeLog                            |    7 ++
 .../gdb.base/multi-line-starts-subshell.exp        |   55 ++++++++++++++++++
 gdb/testsuite/gdb.python/python.exp                |   16 +++++
 gdb/top.c                                          |   19 ++++--
 8 files changed, 204 insertions(+), 11 deletions(-)
 create mode 100644 gdb/testsuite/gdb.base/multi-line-starts-subshell.exp
Comment 5 cvs-commit@gcc.gnu.org 2014-10-29 18:15:21 UTC
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "gdb and binutils".

The branch, gdb-7.8-branch has been updated
       via  cbd6f6bf80881be4628622e369baafb337589578 (commit)
      from  c9792faa1e25cb54edf55ffce93582370c99e4ac (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=cbd6f6bf80881be4628622e369baafb337589578

commit cbd6f6bf80881be4628622e369baafb337589578
Author: Pedro Alves <palves@redhat.com>
Date:   Thu Oct 23 17:13:35 2014 +0100

    PR python/17372 - Python hangs when displaying help()
    
    This is more of a readline/terminal issue than a Python one.
    
    PR17372 is a regression in 7.8 caused by the fix for PR17072:
    
     commit 0017922d0292d8c374584f6100874580659c9973
     Author: Pedro Alves <palves@redhat.com>
     Date:   Mon Jul 14 19:55:32 2014 +0100
    
        Background execution + pagination aborts readline/gdb
    
        gdb_readline_wrapper_line removes the handler after a line is
        processed.  Usually, we'll end up re-displaying the prompt, and that
        reinstalls the handler.  But if the output is coming out of handling
        a stop event, we don't re-display the prompt, and nothing restores the
        handler.  So the next input wakes up the event loop and calls into
        readline, which aborts.
    ...
        gdb/
        2014-07-14  Pedro Alves  <palves@redhat.com>
    
            PR gdb/17072
            * top.c (gdb_readline_wrapper_line): Tweak comment.
            (gdb_readline_wrapper_cleanup): If readline is enabled, reinstall
            the input handler callback.
    
    The problem is that installing the input handler callback also preps
    the terminal, putting it in raw mode and with echo disabled, which is
    bad if we're going to call a command that assumes cooked/canonical
    mode, and echo enabled, like in the case of the PR, Python's
    interactive shell.  Another example I came up with that doesn't depend
    on Python is starting a subshell with "(gdb) shell /bin/sh" from a
    multi-line command.  Tests covering both these examples are added.
    
    The fix is to revert the original fix for PR gdb/17072, and instead
    restore the callback handler after processing an asynchronous target
    event.
    
    Furthermore, calling rl_callback_handler_install when we already have
    some input in readline's line buffer discards that input, which is
    obviously a bad thing to do while the user is typing.  No specific
    test is added for that, because I first tried calling it even if the
    callback handler was still installed and that resulted in hundreds of
    failures in the testsuite.
    
    gdb/
    2014-10-29  Pedro Alves  <palves@redhat.com>
    
    	PR python/17372
    	* event-top.c (change_line_handler): Call
    	gdb_rl_callback_handler_remove instead of
    	rl_callback_handler_remove.
    	(callback_handler_installed): New global.
    	(gdb_rl_callback_handler_remove, gdb_rl_callback_handler_install)
    	(gdb_rl_callback_handler_reinstall): New functions.
    	(display_gdb_prompt): Call gdb_rl_callback_handler_remove and
    	gdb_rl_callback_handler_install instead of
    	rl_callback_handler_remove and rl_callback_handler_install.
    	(gdb_disable_readline): Call gdb_rl_callback_handler_remove
    	instead of rl_callback_handler_remove.
    	* event-top.h (gdb_rl_callback_handler_remove)
    	(gdb_rl_callback_handler_install)
    	(gdb_rl_callback_handler_reinstall): New declarations.
    	* infrun.c (reinstall_readline_callback_handler_cleanup): New
    	cleanup function.
    	(fetch_inferior_event): Install it.
    	* top.c (gdb_readline_wrapper_line) Call
    	gdb_rl_callback_handler_remove instead of
    	rl_callback_handler_remove.
    	(gdb_readline_wrapper_cleanup): Don't call
    	rl_callback_handler_install.
    
    gdb/testsuite/
    2014-10-29  Pedro Alves  <palves@redhat.com>
    
    	PR python/17372
    	* gdb.python/python.exp: Test a multi-line command that spawns
    	interactive Python.
    	* gdb.base/multi-line-starts-subshell.exp: New file.

-----------------------------------------------------------------------

Summary of changes:
 gdb/ChangeLog                                      |   26 ++++++++
 gdb/event-top.c                                    |   61 ++++++++++++++++++--
 gdb/event-top.h                                    |   11 ++++
 gdb/infrun.c                                       |   20 +++++++
 gdb/testsuite/ChangeLog                            |    7 ++
 .../gdb.base/multi-line-starts-subshell.exp        |   55 ++++++++++++++++++
 gdb/testsuite/gdb.python/python.exp                |   16 +++++
 gdb/top.c                                          |   19 ++++--
 8 files changed, 204 insertions(+), 11 deletions(-)
 create mode 100644 gdb/testsuite/gdb.base/multi-line-starts-subshell.exp