[gdb/testsuite] Fix gdb.threads/manythreads.exp with check-read1
authorTom de Vries <tdevries@suse.de>
Sat, 4 Jun 2022 09:16:22 +0000 (11:16 +0200)
committerTom de Vries <tdevries@suse.de>
Sat, 4 Jun 2022 09:16:22 +0000 (11:16 +0200)
When running test-case gdb.threads/manythreads.exp with check-read1, I ran
into this hard-to-reproduce FAIL:
...
[New Thread 0x7ffff7318700 (LWP 31125)]^M
[Thread 0x7ffff7321700 (LWP 31124) exited]^M
[New T^C^M
^M
Thread 769 "manythreads" received signal SIGINT, Interrupt.^M
[Switching to Thread 0x7ffff6d66700 (LWP 31287)]^M
0x00007ffff7586a81 in clone () from /lib64/libc.so.6^M
(gdb) FAIL: gdb.threads/manythreads.exp: stop threads 1
...

The matching in the failing gdb_test_multiple is done in an intricate way,
trying to pass on some order and fail on another order.

Fix this by rewriting the regexps to match one line at most, and detecting
invalid order by setting and checking state variables.

Tested on x86_64-linux.

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

gdb/testsuite/gdb.threads/manythreads.exp

index f2b8bb791c6eaf8630f86f51943f1477170d9779..8e0df3ef95cfa95fd6ec3d9827d2f118debce1c3 100644 (file)
@@ -63,21 +63,12 @@ proc interrupt_and_wait { message } {
 
     send_gdb "\003"
 
+    set saw_signal 0
+    set order_ok 1
     gdb_test_multiple "" $message {
-       -re "\\\[New \[^\]\]*\\\]\r\n" {
-           exp_continue
-       }
-       -re "\\\[\[^\]\]* exited\\\]\r\n" {
-           exp_continue
-       }
-       -re " received signal SIGINT.*$gdb_prompt $" {
-           pass "$message"
-       }
-       -re "$gdb_prompt $" {
-           # Note that with this regex order, if GDB emits [New
-           # Thread ...] output between "Thread NNN received signal"
-           # and the prompt, the "received signal" regex won't match.
-           # That's good, as if we see that happening, it's a
+       -re "\r\n\\\[New \[^\r\n\]*(?=\r\n)" {
+           # Note if GDB emits [New Thread ...] output between
+           # "Thread NNN received signal" and the prompt, it's a
            # regression.
            #
            # GDB makes sure to notify about signal stops, end of
@@ -100,7 +91,20 @@ proc interrupt_and_wait { message } {
            #  foo () at foo.c:31
            #  31      bar ();
            #
-           fail $message
+           if { $saw_signal } {
+               set order_ok 0
+           }
+           exp_continue
+       }
+       -re "\r\n\\\[\[^\r\n]* exited\\\](?=\r\n)" {
+           exp_continue
+       }
+       -re "\r\n\[^\r\n]* received signal SIGINT\[^\r\n\]*(?=\r\n)" {
+           set saw_signal 1
+           exp_continue
+       }
+       -re -wrap "" {
+           gdb_assert {$saw_signal && $order_ok} $gdb_test_name
        }
     }
 }