From: Tom de Vries <tdevries@suse.de>
To: gdb-patches@sourceware.org
Cc: Tom Tromey <tom@tromey.com>
Subject: [PATCH 2/2] [gdb/dap] Fix stray KeyboardInterrupt after cancel
Date: Fri, 23 Feb 2024 17:51:28 +0100 [thread overview]
Message-ID: <20240223165128.32211-2-tdevries@suse.de> (raw)
In-Reply-To: <20240223165128.32211-1-tdevries@suse.de>
When running test-case gdb.dap/pause.exp 100 times in a loop, it passes
100/100.
But if we remove the two "sleep 0.2" from the test-case, we run into
(copied from dap.log and edited for readability):
...
Traceback (most recent call last):
File "startup.py", line 251, in message
def message():
KeyboardInterrupt
Quit
...
This happens as follows.
CancellationHandler.cancel calls gdb.interrupt to cancel a request in flight.
The idea is that this interrupt triggers while in fn here in message (a nested
function of send_gdb_with_response):
...
def message():
try:
val = fn()
result_q.put(val)
except (Exception, KeyboardInterrupt) as e:
result_q.put(e)
...
but instead it triggers outside the try/except.
Fix this by:
- in CancellationHandler, adding an variable interruptable to track whether
we're in the try/except,
- in CancellationHandler.cancel, setting a variable cancel_pending instead
of callling gdb.interrupt if not in the try/except, and
- handling cancel_pending in a few places.
This makes the test-case pass 100/100, also when adding the extra stressor of
"taskset -c 0", which makes the fail more likely without the patch.
I left the two "sleep 0.2" in the test-case, I didn't see a reason to remove
those.
Tested on aarch64-linux.
PR dap/31275
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31275
---
gdb/python/lib/gdb/dap/server.py | 42 ++++++++++++++++++++++++++++++--
1 file changed, 40 insertions(+), 2 deletions(-)
diff --git a/gdb/python/lib/gdb/dap/server.py b/gdb/python/lib/gdb/dap/server.py
index ecec41cc321..0b27d23da1e 100644
--- a/gdb/python/lib/gdb/dap/server.py
+++ b/gdb/python/lib/gdb/dap/server.py
@@ -62,6 +62,8 @@ class CancellationHandler:
# The request currently being handled, or None.
self.in_flight = None
self.reqs = []
+ self.interruptable = False
+ self.cancel_pending = False
def starting(self, req):
"""Call at the start of the given request.
@@ -87,7 +89,10 @@ class CancellationHandler:
If the request has not yet been seen, the cancellation is queued."""
with self.lock:
if req == self.in_flight:
- gdb.interrupt()
+ if self.interruptable:
+ gdb.interrupt()
+ else:
+ self.cancel_pending = True
else:
# We don't actually ignore the request here, but in
# the 'starting' method. This way we don't have to
@@ -97,6 +102,29 @@ class CancellationHandler:
# to try to check for this.
heapq.heappush(self.reqs, req)
+ def is_cancel_pending(self):
+ """Is a cancellation pending. This can only be true when not in the
+ interruptable state."""
+ with self.lock:
+ if not self.cancel_pending:
+ return False
+ self.cancel_pending = False
+ return True
+
+ def enter_interruptable(self):
+ """Enter the interruptable state."""
+ with self.lock:
+ if self.cancel_pending:
+ self.cancel_pending = False
+ return False
+ self.interruptable = True
+ return True
+
+ def exit_interruptable(self):
+ """Exit the interruptable state."""
+ with self.lock:
+ self.interruptable = False
+
class Server:
"""The DAP server class."""
@@ -159,6 +187,9 @@ class Server:
result["success"] = False
result["message"] = str(e)
self.canceller.done(req)
+ if self.canceller.is_cancel_pending():
+ result["success"] = False
+ result["message"] = "cancelled"
return result
# Read inferior output and sends OutputEvents to the client. It
@@ -435,12 +466,19 @@ def send_gdb_with_response(fn):
def message():
try:
- val = fn()
+ if not _server.canceller.enter_interruptable():
+ raise KeyboardInterrupt()
+ try:
+ val = fn()
+ finally:
+ _server.canceller.exit_interruptable()
result_q.put(val)
except (Exception, KeyboardInterrupt) as e:
result_q.put(e)
send_gdb(message)
+ if _server.canceller.is_cancel_pending():
+ result_q.put(KeyboardInterrupt())
val = result_q.get()
if isinstance(val, (Exception, KeyboardInterrupt)):
raise val
--
2.35.3
next prev parent reply other threads:[~2024-02-23 16:51 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-23 16:51 [PATCH 1/2] [gdb/dap] Move send_gdb_with_response to server module Tom de Vries
2024-02-23 16:51 ` Tom de Vries [this message]
2024-02-23 17:27 ` [PATCH 2/2] [gdb/dap] Fix stray KeyboardInterrupt after cancel Tom Tromey
2024-02-26 12:24 ` Tom de Vries
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240223165128.32211-2-tdevries@suse.de \
--to=tdevries@suse.de \
--cc=gdb-patches@sourceware.org \
--cc=tom@tromey.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).