This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug remote/17028] New: GDB+GDBserver hangs on Windows waiting for stop event since target-async on by default
- From: "brobecker at gnat dot com" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Thu, 05 Jun 2014 20:57:43 +0000
- Subject: [Bug remote/17028] New: GDB+GDBserver hangs on Windows waiting for stop event since target-async on by default
- Auto-submitted: auto-generated
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.