[Bug gdb/22992] GDB and Microsoft Windows thread pool

palves at redhat dot com sourceware-bugzilla@sourceware.org
Thu Oct 3 18:22:00 GMT 2019


--- Comment #13 from Pedro Alves <palves at redhat dot com> ---
(In reply to Tom Tromey from comment #11)
> One thing I notice is that the spurious stop is always a "breakpoint"
> stop in some other thread, one that is ostensibly suspended:
> infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=1, current
> thread [Thread 5924.0x2360] at 0x4015d6
> gdb: windows_resume (pid=5924, tid=0x2360, step=1, sig=0);
> ContinueDebugEvent (cpid=5924, ctid=0x2360, DBG_CONTINUE);
> infrun: prepare_to_wait
> gdb: kernel event for pid=5924 tid=0x33a8 code=EXCEPTION_DEBUG_EVENT)
> gdb: Target exception EXCEPTION_BREAKPOINT at 0x4015d6
> get_windows_debug_event - unexpected stop in 0x33a8 (expecting 0x2360)

And supposedly, the breakpoint is NOT installed in the target at this point,
right?  Or is it some other breakpoint?  Seems like it's the same from your
logs.  If it is indeed the breakpoint that was removed, then that again
suggests this is Windows returning the queued event.

SuspendThread returns the thread's previous suspend count.  You could use that
to check whether the program is unsuspending threads on its own.

> I am thinking it might be ok to simply ignore such events.

Does Windows decrement the PC after a break automatically?  I forget.

> I'm a little troubled by all this because I don't truly understand
> how this stop could happen, even in theory.

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

More information about the Gdb-prs mailing list