From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id E3A45385E038; Wed, 14 Feb 2024 13:56:43 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E3A45385E038 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1707919003; bh=muSkg84pa+pldHII5ZcBgFpIVA6x7mhDfrrnUstOJqw=; h=From:To:Subject:Date:From; b=Tzjp2pUoE1mg09Pcs2b8XQPD2qdm2c0Qn39ZU1DpW4xqD3Jlg2ONjmvDQsb1hIEK8 ClPgmRhEHOq2ykIiZxj2OgMqyde5oiM4M1qg/d0XQQxAxGSELHGBZSBqlYNB0Son5D xOgI2FdB7WMTF4yduYyi8Nmt+8w1A2VR24RV4TK4= From: "vries at gcc dot gnu.org" To: gdb-prs@sourceware.org Subject: [Bug testsuite/31382] New: [gdb/testsuite] 2 errors instead of 1 reported by _dap_read_json Date: Wed, 14 Feb 2024 13:56:43 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: testsuite 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=3D31382 Bug ID: 31382 Summary: [gdb/testsuite] 2 errors instead of 1 reported by _dap_read_json Product: gdb Version: HEAD Status: NEW Severity: normal Priority: P2 Component: testsuite Assignee: unassigned at sourceware dot org Reporter: vries at gcc dot gnu.org Target Milestone: --- Consider test-case gdb.dap/eof.exp, modified like so: ... diff --git a/gdb/testsuite/gdb.dap/eof.exp b/gdb/testsuite/gdb.dap/eof.exp index 9c17725c0d0..26bad3eeb3f 100644 --- a/gdb/testsuite/gdb.dap/eof.exp +++ b/gdb/testsuite/gdb.dap/eof.exp @@ -30,6 +30,9 @@ if {[dap_initialize] =3D=3D ""} { return } +_dap_wait_for_event "initialized" +return + catch "close -i $gdb_spawn_id" catch "wait -i $gdb_spawn_id" unset gdb_spawn_id ... That works fine (well, unless we run into PR31306). Now, if we add another _dap_wait_for_event line like it, we run into a time= out error followed by an eof error: ... Running /data/vries/gdb/src/gdb/testsuite/gdb.dap/eof.exp ... ERROR: timeout reading json header while executing "error "timeout reading json header"" invoked from within "expect { -i exp9 -timeout 10=20 -re "^Content-Length: (\[0-9\]+)\r\n" { set length $expect_out(1,string) exp_continue } -re "^(\[^\r\n\]+)\..." ("uplevel" body line 1) invoked from within "uplevel $body" NONE timeout reading json header ERROR: tcl error sourcing /data/vries/gdb/src/gdb/testsuite/gdb.dap/eof.exp. ERROR: eof reading json header while executing "error "eof reading json header"" ("uplevel" body line 2) invoked from within "uplevel $error_sect" invoked from within "remote_expect host 10 { -re "^Content-Length: (\[0-9\]+)\r\n" { set length $expect_out(1,string) exp_continue } -re "^(\[^\r\n\]+)\r\n" {..." ("uplevel" body line 1) invoked from within "uplevel remote_expect host $tmt $expcode" invoked from within "gdb_expect { -re "^Content-Length: (\[0-9\]+)\r\n" { set length $expect_out(1,string) exp_continue } -re "^(\[^\r\n\]+)\r\n" { # Any..." (procedure "_dap_read_json" line 3) invoked from within "_dap_read_json" (procedure "_dap_wait_for_event" line 7) invoked from within "_dap_wait_for_event "initialized"" (file "/data/vries/gdb/src/gdb/testsuite/gdb.dap/eof.exp" line 34) invoked from within "source /data/vries/gdb/src/gdb/testsuite/gdb.dap/eof.exp" ("uplevel" body line 1) invoked from within "uplevel #0 source /data/vries/gdb/src/gdb/testsuite/gdb.dap/eof.exp" invoked from within "catch "uplevel #0 source $test_file_name"" ... This is caused by using calls to error in these gdb_expect clauses in _dap_read_json: ... timeout { error "timeout reading json header" } eof { error "eof reading json header" } ... Proc gdb_expect uses dejagnu's remote_expect, which has some peculiar seman= tics related to errors: ... # remote_expect works basically the same as standard expect, but it=20=20= =20=20=20=20=20=20=20=20=20=20=20 # also takes care of getting the file descriptor from the specified=20=20= =20=20=20=20=20=20=20=20=20=20=20 # host and also calling the timeout/eof/default section if there is an=20= =20=20=20=20=20=20=20=20=20 # error on the expect call.=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20 #=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20 ... So, the timeout error is caught by gdb_expect, and then printed, after which the "timeout/eof/default" is called, which triggers the eof error. I'm not sure how that proc is supposed to work, so this may or may not be correct behaviour. Either way, it's questionable whether it's a good idea to use error directl= y in gdb_expect clauses. I ran into this when trying to catch the timeout error: ... catch {_dap_wait_for_event initialized} ... which didn't work because the timeout error is caught and printed by remote_expect. Instead, we catch the eof error. --=20 You are receiving this mail because: You are on the CC list for the bug.=