[PATCH] gdb/testsuite: ensure gdb_get_worker_threads succeeds

[Andrew Burgess]

Andrew Burgess <aburgess@redhat.com> writes:

> Sometimes, if I'm testing on a loaded machine, the
> gdb.gdb/index-file.exp test will timeout during some early steps,
> which then cases a TCL error to be thrown later in the test script.
>
> Dejagnu then reports this error once the test run has completed, which
> can be pretty noisy, and isn't really very helpful.
>
> The underlying problem is that if GDB takes too long to load the
> executable (which is GDB itself in this test) then GDB will still be
> busy loading the executable when dejagnu moves on and call
> gdb_get_worker_threads.  The gdb_get_worker_threads call itself times
> out as GDB is _still_ busy loading the executable, and so
> gdb_get_worker_threads returns the string "UNKNOWN".
>
> Later we try to perform arithmetic on the worker thread count, which
> results in errors when we try to do 'UNKNOWN / 2'.
>
> I propose that after calling gdb_get_worker_threads, we check if the
> result was UNKNOWN.  If it was then we should report an UNRESOLVED and
> abandon the test, this avoids the later TCL errors.

I went ahead and pushed this patch.

Thanks,
Andrew


> ---
>  gdb/testsuite/gdb.gdb/index-file.exp | 5 +++++
>  1 file changed, 5 insertions(+)
>
> diff --git a/gdb/testsuite/gdb.gdb/index-file.exp b/gdb/testsuite/gdb.gdb/index-file.exp
> index 72088ca41ee..069c7ccac8e 100644
> --- a/gdb/testsuite/gdb.gdb/index-file.exp
> +++ b/gdb/testsuite/gdb.gdb/index-file.exp
> @@ -38,6 +38,11 @@ with_timeout_factor $timeout_factor {
>  # Record how many worker threads GDB is using.
>  set worker_threads [gdb_get_worker_threads]
>  
> +if { $worker_threads eq "UNKNOWN" } {
> +    unresolved "unable to get worker thread count"
> +    return -1
> +}
> +
>  # Generate an index file.
>  set dir1 [standard_output_file "index_1"]
>  remote_exec host "mkdir -p ${dir1}"
>
> base-commit: de4edfcb949c0d04ec8b49fdfe06267f92618589
> -- 
> 2.25.4