[Bug testsuite/31382] New: [gdb/testsuite] 2 errors instead of 1 reported by _dap_read_json

["vries at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>]

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.