Bug 17147 - with gdbserver + all-stop + async, can't quit gdb because target is running
Summary: with gdbserver + all-stop + async, can't quit gdb because target is running
Status: NEW
Alias: None
Product: gdb
Classification: Unclassified
Component: server (show other bugs)
Version: HEAD
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-07-12 17:01 IST by Doug Evans
Modified: 2014-07-20 22:43 IST (History)
2 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments
testcase (355 bytes, text/x-csrc)
2014-07-12 17:01 IST, Doug Evans
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Doug Evans 2014-07-12 17:01:51 IST
Created attachment 7708 [details]
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."));
Comment 1 Doug Evans 2014-07-12 18:17:09 IST
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).
Comment 2 Pedro Alves 2014-07-15 11:36:39 IST
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.
Comment 3 Doug Evans 2014-07-15 14:50:41 IST
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.
Comment 4 Doug Evans 2014-07-15 15:52:41 IST
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.]
Comment 5 Pedro Alves 2014-07-15 19:16:38 IST
Re. message: yeah, that'd be fine with me.
Comment 6 dje 2014-07-17 16:38:26 IST
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---
Comment 7 cvs-commit@gcc.gnu.org 2014-07-20 22:38:50 IST
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(-)
Comment 8 cvs-commit@gcc.gnu.org 2014-07-20 22:43:57 IST
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(-)