This is the mail archive of the gdb-prs@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]