Hello Guinevere,
Guinevere Larsen <blar...@redhat.com> writes:
> I just checked out this regression but I think there's something odd going on
> in the setup
> that is running the tests. When I run the test locally, the relevant part of
> the logs
> looks like this:
>
> (gdb) PASS: gdb.threads/threadcrash.exp: test_live_inferior: continue to
> breakpoint:
> running to breakpoint
> print $_inferior_thread_count^M
> $1 = 7^M
> (gdb) PASS: gdb.threads/threadcrash.exp: test_live_inferior:
> $thread_count == 7
> thread apply all backtrace^M
> ^M
> < lots of GDB output >
> (gdb) PASS: gdb.threads/threadcrash.exp: test_live_inferior: Get thread
> information
> PASS: gdb.threads/threadcrash.exp: test_live_inferior: $unwind_fail ==
> false
> PASS: gdb.threads/threadcrash.exp: test_live_inferior: $thread_count ==
> [llength
> $test_list]
>
> Whereas the failed log reads like this:
>
> (gdb) PASS: gdb.threads/threadcrash.exp: test_live_inferior: continue to
> breakpoint:
> running to breakpoint
> print $_inferior_thread_count
> $1 = 7PASS: gdb.threads/threadcrash.exp: test_live_inferior:
> $thread_count == 7
>
> (gdb) PASS: gdb.threads/threadcrash.exp: test_live_inferior: Get thread
> information
> PASS: gdb.threads/threadcrash.exp: test_live_inferior: $unwind_fail ==
> false
> FAIL: gdb.threads/threadcrash.exp: test_live_inferior: $thread_count ==
> [llength
> $test_list]
> thread apply all backtrace
>
> Notice how the gdb command to "apply all backtrace", which is used to create
> the test_list
> variable, happens after checking if the variable has been set correctly.
>
> I have no clue how things can get so out of sync...
It gets out of sync because the gdb_test_multiple pattern in
test_thread_count doesn't include the GDB prompt, so that function can
return before GDB prints the prompt. In this case, this pattern in
thread_apply_all will immediately match and make it return before
constructing $test_list:
-re "$::gdb_prompt " {
pass $gdb_test_name
}
That is why the "Get thread information" test passed right after the GDB
prompt printed after the "$thread_count == 7" test.
This patch makes the testcase work reliably for me, in a machine where I
could often reproduce the failure from the CI:
diff --git a/gdb/testsuite/gdb.threads/threadcrash.exp
b/gdb/testsuite/gdb.threads/threadcrash.exp
index 3905ad6f9362..944fbcac1b18 100644
--- a/gdb/testsuite/gdb.threads/threadcrash.exp
+++ b/gdb/testsuite/gdb.threads/threadcrash.exp
@@ -28,7 +28,7 @@ proc test_thread_count {} {
set thread_count 0
gdb_test_multiple "print \$_inferior_thread_count" "getting thread count" {
- -re ".* = (\[0-9]+).*" {
+ -re ".* = (\[0-9]+)\r\n$::gdb_prompt " {
set thread_count $expect_out(1,string)
gdb_assert {$thread_count == 7}
}
--
Thiago
_______________________________________________
linaro-toolchain mailing list -- linaro-toolchain@lists.linaro.org
To unsubscribe send an email to linaro-toolchain-le...@lists.linaro.org
