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

["brobecker at gnat dot com" <sourceware-bugzilla at sourceware dot org>]

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

            Bug ID: 17028
           Summary: GDB+GDBserver hangs on Windows waiting for stop event
                    since target-async on by default
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: remote
          Assignee: unassigned at sourceware dot org
          Reporter: brobecker at gnat dot com

Created attachment 7630
  --> https://sourceware.org/bugzilla/attachment.cgi?id=7630&action=edit
source file.

Since target-async was turned on by default, debugging on x86-windows using
GDB+GDBserver sometimes hangs while waiting for a command that resumed the
program's execution to report that the inferior stopped. The problem seems to
be very racy in nature and does not allways appear, or not always at the same
point in the debugging scenario (probability is about 70-80% of the time when
debug traces are not enabled, it becomes much lower when GDBserver's --debug
option is used, and nearly zero when GDBserver's --remote-debug option is used;
enabling debug traces on the GDB side seem to have little effect on the
probability).

I could reprorduce the problem using the attached file (simple.c), compiled
with GCC on x86-windows:

   % gcc -o simple -g simple.c

In one shell, I started GDBserver:

   % /tardes.a/tmp/brobecke/bld/gdb-public/gdb/gdbserver/gdbserver.exe :4444
simple

In another, I started GDB, set a breakpoint on the first call to "increment",
connected to the target, ran to that breakpoint, and then I do as many "next"
as possible until the debugger hangs. For instance:

    (gdb) b simple.c:12
    Breakpoint 1 at 0x401610: file simple.c, line 12.
    (gdb) tar rem :4444
    Remote debugging using :4444
    0x77d7103c in ntdll!RtlUpcaseUnicodeToOemN ()
       from C:\Windows\SysWOW64\ntdll.dll
    (gdb) c
    Continuing.

    Breakpoint 1, main () at simple.c:12
    12        increment (&i);
    (gdb) n
    13        increment (&i);
    (gdb) n
    14        increment (&i);
    (gdb) n
    [hangs]

After having added ad hoc traces in GDBserver, and turning infrun+remote traces
on the GDB side, it looks like GDB is not receiving a T05 packet that GDBserver
is sending to signal that the step is done.

This is what we see for a faulty next on the GDB side:

    (gdb) n
    infrun: clear_proceed_status_thread (Thread 4424)
    infrun: proceed (addr=0xffffffff, signal=GDB_SIGNAL_DEFAULT, step=1)
    Sending packet: $m401610,1#f6...Packet received: 8d
    Sending packet: $X401610,1:ï#e7...Packet received: OK
    Sending packet: $m763c4b72,1#cc...Packet received: 55
    Sending packet: $X763c4b72,1:ï#bd...Packet received: OK
    infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=0, current
thread [Thread 4424] at 0x401634
    Sending packet: $vCont;s:1148;c#5e...

On the GDBserver side, this is what we see:

    DEBUG: write_prim ($OK#9a)
           -> 6
    handling possible serial event
    DEBUG: write_prim ($8d#9c)
           -> 6
    handling possible serial event
    DEBUG: write_prim ($OK#9a)
           -> 6
    handling possible serial event
    DEBUG: write_prim ($55#6a)
           -> 6
    handling possible serial event
    DEBUG: write_prim ($OK#9a)
           -> 6
    handling possible serial event
    gdbserver: kernel event EXCEPTION_DEBUG_EVENT for pid=4968 tid=1148
    EXCEPTION_SINGLE_STEP
    Child Stopped with signal = 5 
    Writing resume reply for LWP 4968.4424:1
    DEBUG: write_prim ($T0505:c8fe2800;04:a0fe2800;08:38164000;thread:1148;#f0)
           -> 55

The "DEBUG: write_prim" traces show that write_prim was called and what value
it returned. In particular for our last vCont, it eventually sent a T05 packet,
which GDB is waiting for.

At this point, attaching a debugger to the hanging GDB confirms that it is
blocked, waiting for a socket event:

    #6  0x757841d8 in WaitForMultipleObjects ()
       from C:\Windows\syswow64\kernel32.dll
    #7  0x004708e7 in gdb_select (n=469, readfds=0x88ca50 <gdb_notifier+784>, 
        writefds=0x88cb54 <gdb_notifier+1044>, 
        exceptfds=0x88cc58 <gdb_notifier+1304>, timeout=0x0)
        at /[...]/gdb/mingw-hdep.c:172
    #8  0x00527926 in gdb_wait_for_event (block=1)
        at /[...]/gdb/event-loop.c:831
    #9  0x00526ff1 in gdb_do_one_event ()
        at /[...]/gdb/event-loop.c:403

Not sure why the event does not show up on the GDB side, though, and why
target-async makes any difference.

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