Hi!
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...
Hello Guinevere,
Guinevere Larsen blarsen@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} }
Hello again,
Thiago Jung Bauermann thiago.bauermann@linaro.org writes:
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} }
It occurred to me that this gdb_test_multiple call is very similar to the function get_valueof in lib/gdb.exp, so one suggestion is to use that function instead. It uses "-re -wrap" so it expects the GDB prompt.
On 13/02/2024 22:01, Thiago Jung Bauermann wrote:
Hello again,
Thiago Jung Bauermann thiago.bauermann@linaro.org writes:
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} }
It occurred to me that this gdb_test_multiple call is very similar to the function get_valueof in lib/gdb.exp, so one suggestion is to use that function instead. It uses "-re -wrap" so it expects the GDB prompt.
This makes a lot of sense. thanks for the help! And for making this CI, it is clearly making a difference! :D
Guinevere Larsen blarsen@redhat.com writes:
On 13/02/2024 22:01, Thiago Jung Bauermann wrote:
Hello again,
Thiago Jung Bauermann thiago.bauermann@linaro.org writes:
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} }
It occurred to me that this gdb_test_multiple call is very similar to the function get_valueof in lib/gdb.exp, so one suggestion is to use that function instead. It uses "-re -wrap" so it expects the GDB prompt.
This makes a lot of sense. thanks for the help! And for making this CI, it is clearly making a difference! :D
Thank you! We're glad it is helping!
linaro-toolchain@lists.linaro.org