public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
* [Bug testsuite/31382] New: [gdb/testsuite] 2 errors instead of 1 reported by _dap_read_json
@ 2024-02-14 13:56 vries at gcc dot gnu.org
  2024-02-14 14:00 ` [Bug testsuite/31382] " vries at gcc dot gnu.org
                   ` (4 more replies)
  0 siblings, 5 replies; 6+ messages in thread
From: vries at gcc dot gnu.org @ 2024-02-14 13:56 UTC (permalink / raw)
  To: gdb-prs

https://sourceware.org/bugzilla/show_bug.cgi?id=31382

            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] == ""} {
     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 timeout
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 
        -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 semantics
related to errors:
...
# remote_expect works basically the same as standard expect, but it             
# also takes care of getting the file descriptor from the specified             
# host and also calling the timeout/eof/default section if there is an          
# error on the expect call.                                                     
#                                                                               
...

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 directly 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.

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

^ permalink raw reply	[flat|nested] 6+ messages in thread
end of thread, other threads:[~2024-02-21 13:26 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-02-14 13:56 [Bug testsuite/31382] New: [gdb/testsuite] 2 errors instead of 1 reported by _dap_read_json vries at gcc dot gnu.org
2024-02-14 14:00 ` [Bug testsuite/31382] " vries at gcc dot gnu.org
2024-02-14 16:23 ` vries at gcc dot gnu.org
2024-02-21 13:25 ` cvs-commit at gcc dot gnu.org
2024-02-21 13:26 ` vries at gcc dot gnu.org
2024-02-21 13:26 ` vries at gcc dot gnu.org

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).