public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
* [Bug server/17147] New: with gdbserver + all-stop + async, can't quit gdb because target is running
@ 2014-07-12 17:01 xdje42 at gmail dot com
  2014-07-12 18:17 ` [Bug server/17147] " xdje42 at gmail dot com
                   ` (7 more replies)
  0 siblings, 8 replies; 9+ messages in thread
From: xdje42 at gmail dot com @ 2014-07-12 17:01 UTC (permalink / raw)
  To: gdb-prs

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.


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

end of thread, other threads:[~2014-07-20 22:44 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-07-12 17:01 [Bug server/17147] New: with gdbserver + all-stop + async, can't quit gdb because target is running xdje42 at gmail dot com
2014-07-12 18:17 ` [Bug server/17147] " xdje42 at gmail dot com
2014-07-15 11:36 ` palves at redhat dot com
2014-07-15 14:50 ` xdje42 at gmail dot com
2014-07-15 15:52 ` xdje42 at gmail dot com
2014-07-15 19:16 ` palves at redhat dot com
2014-07-17 16:38 ` dje at google dot com
2014-07-20 22:39 ` cvs-commit at gcc dot gnu.org
2014-07-20 22:44 ` cvs-commit at gcc dot gnu.org

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).