Re: [PATCH] Fix random dejagnu test abort with simulator target

[Tom de Vries <tdevries@suse.de>]

On 4/19/24 12:49, Bernd Edlinger wrote:
> This is probably a dejagnu issue with the gdb testsuite
> when a simulator target is used.  I observed random
> testrun aborts with dejagnu 1.6.2-1 from ubuntu 20.04
> The problem starts when the test case gdb.base/sigwinch-notty.exp
> tries to execute "sleep", although that is impossible with a
> simulator.  And for unknown reason the test case completes
> (with errors) before the "after 1000" block is run.
> 
> Then in a totally different test this happens with 50% likelihood:
> 
> ERROR: (DejaGnu) proc "bgerror {can't read "gdb_pid": no such variable}" does not exist.
> The error code is TCL LOOKUP COMMAND bgerror
> The info on the error is:
> invalid command name "bgerror"
>      while executing
> "::tcl_unknown bgerror {can't read "gdb_pid": no such variable}"
>      ("uplevel" body line 1)
>      invoked from within
> "uplevel 1 ::tcl_unknown $args"
> 
>                  === gdb Summary ===
> 
>   # of expected passes            30815
>   # of unexpected failures        241
>   # of expected failures          3
>   # of known failures             23
>   # of unresolved testcases       241
>   # of untested testcases         96
>   # of unsupported tests          532
>   # of paths in test names        1
> 
> So the whole test run is aborted in the middle.
> 
> This patch should fix the issue.
> ---
>   gdb/testsuite/gdb.base/sigwinch-notty.exp | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/gdb/testsuite/gdb.base/sigwinch-notty.exp b/gdb/testsuite/gdb.base/sigwinch-notty.exp
> index cef21c07c59..0f70f0978d2 100644
> --- a/gdb/testsuite/gdb.base/sigwinch-notty.exp
> +++ b/gdb/testsuite/gdb.base/sigwinch-notty.exp
> @@ -21,7 +21,7 @@ require {!target_info exists gdb,nosignals}
>   
>   # The testfile relies on "run" from the command line, so only works
>   # with "target native".
> -if { [target_info gdb_protocol] != "" } {
> +if { [target_info gdb_protocol] != "" || [target_info is_simulator] != ""} {
>       return
>   }
>   

Hi Bernd,

thanks for the report and patch.

[ I ran the test-case using make-check-all.sh, and ran into trouble with 
host/target board local-remote-host-native.

I added some debugging here:
...
  verbose -log "gdb_spawn_id=$gdb_spawn_id"
  verbose -log "gdb_pid=$gdb_pid" 

+verbose -log "gdb_pid: [exec ps -p $gdb_pid]" 

...
and first ran with the default target board unix:
...
gdb_spawn_id=exp6
gdb_pid=28288
gdb_pid:   PID TTY          TIME CMD
28288 pts/3    00:00:00 notty-wrap
...
and then with host+target local-remote-host-native:
...
gdb_spawn_id=exp6
gdb_pid=27827
gdb_pid:   PID TTY          TIME CMD
27827 pts/3    00:00:00 ssh
...

Which is basically the remote host variant of what's explained here for 
remote target:
...
proc can_spawn_for_attach { } {
     # We use exp_pid to get the inferior's pid, assuming that gives 

     # back the pid of the program.  On remote boards, that would give 

     # us instead the PID of e.g., the ssh client, etc. 

     if {[is_remote target]} {
         verbose -log "can't spawn for attach (target is remote)"
         return 0
     }
...

Anyway, this can be fixed using:
...
-if { [target_info gdb_protocol] != "" } {
+if { [target_info gdb_protocol] != "" || [is_remote host] } {
...
]

Back to the problem you reported.

I wonder about using gdb_spawn without checking for the result.  Does it 
still reproduce if we bail out when gdb_spawn fails?

If so, can you show the actual gdb.log for the test-case?

Thanks,
- Tom