[Bug server/17147] New: with gdbserver + all-stop + async, can't quit gdb because target is running

[Bug server/17147] New: with gdbserver + all-stop + async, can't quit gdb because target is running

[xdje42 at gmail dot com]

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

            Bug ID: 17147
           Summary: with gdbserver + all-stop + async, can't quit gdb
                    because target is running
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: server
          Assignee: unassigned at sourceware dot org
          Reporter: xdje42 at gmail dot com

Created attachment 7708
  --> https://sourceware.org/bugzilla/attachment.cgi?id=7708&action=edit
testcase

Seems like it may be too soon to enable asynchronous by default for remote
targets, at least in all-stop mode.

bash1$ gdbserver --once :1234 forever-threads.x64
bash2$ gdb forever-threads.x64
(gdb) tar rem :1234
(gdb) b all_threads_running
(gdb) c
[breakpoint hit]
(gdb) c &
(gdb) q
A debugging session is active.

        Inferior 1 [process 29047] will be killed.

Quit anyway? (y or n) y
Cannot execute this command while the target is running.
(gdb) k
Kill the program being debugged? (y or n) y
Cannot execute this command while the target is running.
(gdb) 

Ouch.

In all-stop nothing can (currently) be sent to gdbserver until the program
stops. remote.c:putpkt_binary:

  /* Catch cases like trying to read memory or listing threads while            
     we're waiting for a stop reply.  The remote server wouldn't be             
     ready to handle this request, so we'd hang and timeout.  We don't          
     have to worry about this in synchronous mode, because in that              
     case it's not possible to issue a command while the target is              
     running.  This is not a problem in non-stop mode, because in that          
     case, the stub is always ready to process serial input.  */
  if (!non_stop && target_can_async_p () && rs->waiting_for_stop_reply)
    error (_("Cannot execute this command while the target is running."));

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

[Bug server/17147] with gdbserver + all-stop + async, can't quit gdb because target is running

[xdje42 at gmail dot com]

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

--- Comment #1 from Doug Evans <xdje42 at gmail dot com> ---
I marked this as a blocker for 7.8 to make sure this gets looked at before 7.8
is released.  I'm not sure yet how best to fix this (in the release or in
trunk).

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

[Bug server/17147] with gdbserver + all-stop + async, can't quit gdb because target is running

[palves at redhat dot com]

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

Pedro Alves <palves at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |palves at redhat dot com

--- Comment #2 from Pedro Alves <palves at redhat dot com> ---
If the user uses only the features she could use before 7.8, nothing changes,
and target-async is completely transparent.  It's only if you use features you
couldn't before (c&) that you get into that situation.  And then, you _could_
get into this situation before too, just not by default (with "set target-async
on" before 7.8).

So it doesn't look like a regression or a 7.8 blocker to me.

Though of course not being able to quit (without interrupting the target first)
is never nice.

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

[Bug server/17147] with gdbserver + all-stop + async, can't quit gdb because target is running

[xdje42 at gmail dot com]

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

--- Comment #3 from Doug Evans <xdje42 at gmail dot com> ---
Although, in the before case one had to manually enable it first or one would
get an error.  Now one doesn't get an error - just a completely hosed session.

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

[Bug server/17147] with gdbserver + all-stop + async, can't quit gdb because target is running

[xdje42 at gmail dot com]

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

--- Comment #4 from Doug Evans <xdje42 at gmail dot com> ---
One thought would be to print a message either with commands that resume the
inferior in the background, or with the "Cannot execute this command while the
target is running." error message.

E.g.

Cannot execute this command while the target is running.
Use the "interrupt" command to stop the target.

or perhaps a teensy bit better,

Cannot execute this command while the target is running.
Use the "interrupt" command to stop the target and then try again.

[side note: why does "interrupt -a" have to be an error in all-stop mode?
Instead just treat "interrupt -a" == "interrupt".  Filed bug 17160.]

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

[Bug server/17147] with gdbserver + all-stop + async, can't quit gdb because target is running

[palves at redhat dot com]

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

--- Comment #5 from Pedro Alves <palves at redhat dot com> ---
Re. message: yeah, that'd be fine with me.

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

[Bug server/17147] with gdbserver + all-stop + async, can't quit gdb because target is running

[dje at google dot com]

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

dje at google dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dje at google dot com

--- Comment #6 from dje at google dot com ---
I think a doc update is also required.
The doc refers to execution commands only, however with gdbserver one can't
even do things like "info threads" until the target stops.


---snip---
Background execution is especially useful in conjunction with non-stop
mode for debugging programs with multiple threads; see @ref{Non-Stop Mode}.
However, you can also use these commands in the normal all-stop mode with
the restriction that you cannot issue another execution command until the
previous one finishes.  Examples of commands that are valid in all-stop
mode while the program is running include @code{help} and @code{info break}.
---snip---

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

[Bug server/17147] with gdbserver + all-stop + async, can't quit gdb because target is running

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
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  9597b22adf3552a5617d73104d8facd6a7aea881 (commit)
      from  91101fe524e5ae8a912880bf3350ad93d511181a (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=9597b22adf3552a5617d73104d8facd6a7aea881

commit 9597b22adf3552a5617d73104d8facd6a7aea881
Author: Doug Evans <dje@google.com>
Date:   Sun Jul 20 15:36:23 2014 -0700

    Improve error message to cope with pr 17147.

        PR server/17147
        * remote.c (putpkt_binary): Add text to error message.

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

Summary of changes:
 gdb/ChangeLog |    5 +++++
 gdb/remote.c  |    6 +++++-
 2 files changed, 10 insertions(+), 1 deletions(-)

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

[Bug server/17147] with gdbserver + all-stop + async, can't quit gdb because target is running

[cvs-commit at gcc dot gnu.org]

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

--- Comment #8 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
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  933f5a202ed484a2d727d0bfc7a38f2983e18646 (commit)
      from  40bf817af867e1c601da9a16fd158eca1351dad9 (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=933f5a202ed484a2d727d0bfc7a38f2983e18646

commit 933f5a202ed484a2d727d0bfc7a38f2983e18646
Author: Doug Evans <dje@google.com>
Date:   Sun Jul 20 15:42:02 2014 -0700

    Improve error message to cope with pr 17147.

        PR server/17147
        * remote.c (putpkt_binary): Add text to error message.

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

Summary of changes:
 gdb/ChangeLog |    5 +++++
 gdb/remote.c  |    6 +++++-
 2 files changed, 10 insertions(+), 1 deletions(-)

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