From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id E1A1E385DC03; Wed, 14 Feb 2024 11:23:15 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E1A1E385DC03 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1707909795; bh=TP6IvJe1+mPpAupF8NDC/bP4h523VY+6RNbmr4rzkY8=; h=From:To:Subject:Date:From; b=bkPnaoEW96zW7N4k5njqhSAQv7EAN41yFlp2SJQakQcjvoRInqmZDd1zq3a7qST4L joJdSv2UvfImbGPql1geS9pR0uPVocuFeSIOMzTiWFCN77f/Q4gr4ignXl7HutQDY/ IPRo87kwvSTtEraUhol5xAL5XrlHmsljmXU5Arek= From: "vries at gcc dot gnu.org" To: gdb-prs@sourceware.org Subject: [Bug dap/31380] New: [gdb/dap] Ensure responses are flushed to client before exiting Date: Wed, 14 Feb 2024 11:23:14 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: dap X-Bugzilla-Version: HEAD X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: vries at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D31380 Bug ID: 31380 Summary: [gdb/dap] Ensure responses are flushed to client before exiting Product: gdb Version: HEAD Status: NEW Severity: normal Priority: P2 Component: dap Assignee: unassigned at sourceware dot org Reporter: vries at gcc dot gnu.org Target Milestone: --- In dap, we want to flush responses to the client before exiting, as stated = here in main_loop: ... # Got the terminate request. This is handled by the=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 # JSON-writing thread, so that we can ensure that all=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 # responses are flushed to the client before exiting.=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 self.write_queue.put(None) ... Now that we print ": terminating" message, we can check for this (by proxy) by doing: ... diff --git a/gdb/testsuite/gdb.dap/eof.exp b/gdb/testsuite/gdb.dap/eof.exp index 9c17725c0d0..575a98d6042 100644 --- a/gdb/testsuite/gdb.dap/eof.exp +++ b/gdb/testsuite/gdb.dap/eof.exp @@ -35,3 +35,4 @@ catch "wait -i $gdb_spawn_id" unset gdb_spawn_id dap_check_log_file +dap_check_log_file_re "JSON writer: terminating" diff --git a/gdb/testsuite/lib/dap-support.exp b/gdb/testsuite/lib/dap-support.exp index 979dfa2cd73..b56d8bee244 100644 --- a/gdb/testsuite/lib/dap-support.exp +++ b/gdb/testsuite/lib/dap-support.exp @@ -358,6 +358,17 @@ proc dap_check_log_file {} { } } +proc dap_check_log_file_re { re } { + global dap_gdb_instance + + set fd [open [standard_output_file "dap.log.$dap_gdb_instance"]] + set contents [read $fd] + close $fd + + set ok [regexp $re $contents] + gdb_assert {$ok} "log file matched $re" +} + # Cleanly shut down gdb. TERMINATE is passed as the terminateDebuggee # parameter to the request. proc dap_shutdown {{terminate false}} { ... This currently fails more often than not: ... FAIL: gdb.dap/eof.exp: log file matched JSON writer: terminating ... This ( https://sourceware.org/pipermail/gdb-patches/2024-February/206416.ht= ml ) mentions: ... However, I suppose this approach does not really work, because main_loop th= en proceeds to return. One way to fix this would be to have start_json_writer return the thread object, and then have main_loop join the thread to terminate after writing the None. This would mean making this particular thread non-daemon though. ... I posted a first attempt at fixing this here ( https://sourceware.org/pipermail/gdb-patches/2024-February/206568.html ): ... diff --git a/gdb/python/lib/gdb/dap/io.py b/gdb/python/lib/gdb/dap/io.py index 5149edae977..491cf208ae3 100644 --- a/gdb/python/lib/gdb/dap/io.py +++ b/gdb/python/lib/gdb/dap/io.py @@ -65,10 +65,7 @@ def start_json_writer(stream, queue): while True: obj =3D queue.get() if obj is None: - # This is an exit request. The stream is already - # flushed, so all that's left to do is request an - # exit. - send_gdb("quit") + queue.task_done() break obj["seq"] =3D seq seq =3D seq + 1 @@ -79,5 +76,6 @@ def start_json_writer(stream, queue): stream.write(header_bytes) stream.write(body_bytes) stream.flush() + queue.task_done() start_thread("JSON writer", _json_writer) diff --git a/gdb/python/lib/gdb/dap/server.py b/gdb/python/lib/gdb/dap/server.py index 7cc5a4681ee..ca4465ff207 100644 --- a/gdb/python/lib/gdb/dap/server.py +++ b/gdb/python/lib/gdb/dap/server.py @@ -229,6 +229,8 @@ class Server: # JSON-writing thread, so that we can ensure that all # responses are flushed to the client before exiting. self.write_queue.put(None) + self.write_queue.join() + send_gdb("quit") @in_dap_thread def send_event_later(self, event, body=3DNone): ... But I still run into the same fail. All that this patch does is guarantee that the dap main thread doesn't fini= sh before the JSON writer thread. But there's a race with the SIGHUP that's handled by GDB's main thread. AF= AIU there's nothing guaranteeing that the dap main thread finishes before GDB's main thread. If we're going to add such a constraint, it could make sense to stop dap earlier, before GDB's main thread looses the ability to handle posted (pyth= on) events. --=20 You are receiving this mail because: You are on the CC list for the bug.=