]> git.ipfire.org Git - thirdparty/binutils-gdb.git/commit
Fix DAP defer_stop_events implementation
authorTom Tromey <tromey@adacore.com>
Thu, 13 Feb 2025 14:24:08 +0000 (07:24 -0700)
committerTom Tromey <tromey@adacore.com>
Mon, 2 Jun 2025 17:46:53 +0000 (11:46 -0600)
commitcbaa41b3302e15ead6af1d21de9140c02d6c7ab5
treed2d617544810dd15f87d314e0cf4b21c2a607eae
parent568ec5b9831b0d6abc7aff4e76cefcc0fa7e0c5e
Fix DAP defer_stop_events implementation

DAP requests have a "defer_stop_events" option that is intended to
defer the emission of any "stopped" event until after the current
request completes.  This was needed to handle async continues like
"finish &".

However, I noticed that sometimes DAP tests can fail, because a stop
event does arrive before the response to the "stepOut" request.  I've
only noticed this when the machine is fairly loaded -- for instance
when I'm regression-testing a series, it may occur in some of the
tests mid-series.

I believe the problem is that the implementation in the "request"
function is incorrect -- the flag is set when "request" is invoked,
but instead it must be deferred until the request itself is run.  That
is, the setting must be captured in one of the wrapper functions.

Following up on this, Simon pointed out that introducing a delay
before sending a request's response will cause test case failures.
That is, there's a race here that is normally hidden.

Investigation showed that that deferred requests can't force event
deferral.  This patch implements this; but more testing showed many
more race failures.  Some of these are due to how the test suite is
written.

Anyway, in the end I took the radical approach of deferring all events
by default.  Most DAP requests are asynchronous by nature, so this
seemed ok.  The only case I found that really required this is
pause.exp, where the test (rightly) expects to see a 'continued' event
while performing an inferior function call.

I went through all events and all requests and tried to convince
myself that this patch will cause acceptable behavior in every case.
However, it's hard to be completely sure about this approach.  Maybe
there are cases that do still need an event before the response, but
we just don't have tests for them.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32685
Acked-By: Simon Marchi <simon.marchi@efficios.com>
gdb/python/lib/gdb/dap/evaluate.py
gdb/python/lib/gdb/dap/events.py
gdb/python/lib/gdb/dap/next.py
gdb/python/lib/gdb/dap/server.py
gdb/testsuite/gdb.dap/attach.exp