From b0056f89497ce28e88b275250099d4fab0999c0a Mon Sep 17 00:00:00 2001 From: Andrew Burgess Date: Sun, 9 Jun 2024 20:28:36 +0100 Subject: gdb/testsuite: ensure gdb_get_worker_threads succeeds 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. --- 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 72088ca..069c7cc 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}" -- cgit v1.1