[Bug remote/17028] GDB+GDBserver hangs on Windows waiting for stop event since target-async on by default

["palves at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

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

--- Comment #13 from Pedro Alves <palves at redhat dot com> ---
I think I found the race.  I'd added some debug logs to ser-mingw.c, and this
is what I see:

w $][v][C][o][n][t][;][s][:][1][0][5][c][;][c][#][8][9][fd364->asynchronous]
[fd364->fd-scheduled]
net_windows_select_thread: WaitForMultipleObjects blocking     
net_windows_select_thread: WaitForMultipleObjects returned 1   (***)
gdb_select: WaitForMultipleObjects blocking (t=0)
gdb_select: WaitForMultipleObjects returned 102
gdb_select: WAIT_TIMEOUT
net_windows_select_thread: WaitForMultipleObjects blocking
gdb_select: WaitForMultipleObjects blocking (INFINITE)

Notice the line at (***), just above.  That indicates that the select thread
noticed data was available.  But, gdb_select was called with timeout == 0, IOW,
it was just a non-blocking poll ("is there data ready now?").  Recall that is
running on a separate thread.  That WaitForMultipleObjects manages to run
before net_windows_select_thread sets state->base.read_event, and returns
WAIT_TIMEOUT.  GDB then goes back to the event loop, and calls a
blocking/infinite gdb_select.  This loops through all fds, and calls 
net_windows_wait_handle.  Recall that state->base.read_event is set, with data
waiting to be consumed.  But look, net_windows_wait_handle clears 
state->base.read_event!

This #if 0 seems to fix it for me:

static void
net_windows_wait_handle (struct serial *scb, HANDLE *read, HANDLE *except)
{
  struct net_windows_state *state = scb->state;
  /* Start from a clean slate.  */
#if 0
  ResetEvent (state->base.read_event);
  ResetEvent (state->base.except_event);
#endif
  ResetEvent (state->base.stop_select);

I haven't thought through consequences, but seems quite promising.

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