forked from Imagelibrary/binutils-gdb
The gdb.threads/thread-specific-bp.exp test has been a little problematic, see commits: commit89702edd93Date: Thu Mar 9 12:31:26 2023 +0100 [gdb/testsuite] Fix gdb.threads/thread-specific-bp.exp on native-gdbserver and commit2e5843d87cDate: Fri Nov 19 14:33:39 2021 +0100 [gdb/testsuite] Fix gdb.threads/thread-specific-bp.exp But I recently saw a test failure for that test, which looked like this: ... (gdb) PASS: gdb.threads/thread-specific-bp.exp: non_stop=on: thread 1 selected continue -a Continuing. Thread 1 "thread-specific" hit Breakpoint 4, end () at /tmp/binutils-gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.threads/thread-specific-bp.c:29 29 } (gdb) [Thread 0x7ffff7c5c700 (LWP 1552086) exited] Thread-specific breakpoint 3 deleted - thread 2 no longer in the thread list. FAIL: gdb.threads/thread-specific-bp.exp: non_stop=on: continue to end (timeout) ... This only crops up (for me) when running on a loaded machine, and still only occurs sometimes. I've had to leave the test running in a loop for 10+ minutes sometimes in order to see the failure. The problem is that we use gdb_test_multiple to try and match two patterns: (1) The 'Thread-specific breakpoint 3 deleted ....' message, and (2) The GDB prompt. As written in the test, we understand that these patterns can occur in any order, and we have a flag for each pattern. Once both patterns have been seen then we PASS the test. The problem is that once expect has matched a pattern, everything up to, and including the matched text is discarded from the input buffer. Thus, if the input buffer contains: <PATTERN 2><PATTERN 1> Then expect will first try to match <PATTERN 1>, which succeeds, and then expect discards the entire input buffer up to the end of the <PATTERN 1>. As a result, we will never spot <PATTERN 2>. Obviously we can't just reorder the patterns within the gdb_test_multiple, as the output can legitimately (and most often does) occur in the other order, in which case the test would mostly fail, and only occasionally pass! I think the easiest solution here is just to have the gdb_test_multiple contain two patterns, each pattern consists of the two parts, but in the alternative orders, thus, for a particular output configuration, only one regexp will match. With this change in place, I no longer see the intermittent failure. Approved-By: Tom Tromey <tom@tromey.com>
125 lines
3.2 KiB
Plaintext
125 lines
3.2 KiB
Plaintext
# Copyright (C) 2013-2023 Free Software Foundation, Inc.
|
|
|
|
# This program is free software; you can redistribute it and/or modify
|
|
# it under the terms of the GNU General Public License as published by
|
|
# the Free Software Foundation; either version 3 of the License, or
|
|
# (at your option) any later version.
|
|
#
|
|
# This program is distributed in the hope that it will be useful,
|
|
# but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
# GNU General Public License for more details.
|
|
#
|
|
# You should have received a copy of the GNU General Public License
|
|
# along with this program. If not, see <http://www.gnu.org/licenses/>.
|
|
#
|
|
# Verify that a thread-specific breakpoint is deleted when the
|
|
# corresponding thread is gone.
|
|
|
|
standard_testfile
|
|
|
|
if {[gdb_compile_pthreads \
|
|
"${srcdir}/${subdir}/${srcfile}" \
|
|
"${binfile}" executable {debug} ] != "" } {
|
|
return -1
|
|
}
|
|
|
|
# Extract and return the thread ID of the thread stopped at function
|
|
# FUNC.
|
|
|
|
proc get_thread_id {func} {
|
|
global gdb_prompt
|
|
|
|
set thre -1
|
|
set test "get $func thread id"
|
|
gdb_test_multiple "info threads" $test {
|
|
-re "(\[0-9\]+)\[^\n\r\]*Thread\[^\n\r\]*$func.*$gdb_prompt $" {
|
|
# Get the thread's id.
|
|
set thre $expect_out(1,string)
|
|
pass $test
|
|
}
|
|
}
|
|
|
|
return $thre
|
|
}
|
|
|
|
proc check_thread_specific_breakpoint {non_stop} {
|
|
global gdb_prompt
|
|
|
|
if { ![runto_main] } {
|
|
return -1
|
|
}
|
|
|
|
set main_thre [get_thread_id "main"]
|
|
if { $main_thre < 0 } {
|
|
return -1
|
|
}
|
|
|
|
gdb_breakpoint "start"
|
|
gdb_continue_to_breakpoint "start"
|
|
|
|
set start_thre [get_thread_id "start"]
|
|
if { $start_thre < 0 } {
|
|
return -1
|
|
}
|
|
|
|
# Check that multiple uses of 'thread' keyword give an error.
|
|
gdb_test "break main thread $start_thre thread $main_thre" \
|
|
"You can specify only one thread\\."
|
|
|
|
# Set a thread-specific breakpoint at "main". This can't ever
|
|
# be hit, but that's OK.
|
|
gdb_breakpoint "main thread $start_thre"
|
|
gdb_test "info break" ".*breakpoint.*thread $start_thre" "breakpoint set"
|
|
|
|
# Set breakpoint at a place only reachable after the "start"
|
|
# thread exits.
|
|
gdb_breakpoint "end"
|
|
|
|
# Switch back to the main thread, and resume all threads. The
|
|
# "start" thread exits, and the main thread reaches "end".
|
|
gdb_test "thread $main_thre" \
|
|
"Switching to thread $main_thre.*" \
|
|
"thread $main_thre selected"
|
|
|
|
if { $non_stop } {
|
|
set cmd "continue -a"
|
|
} else {
|
|
set cmd "continue"
|
|
}
|
|
set msg_re \
|
|
[join \
|
|
[list \
|
|
"Thread-specific breakpoint 3 deleted" \
|
|
"-" \
|
|
"thread 2 no longer in the thread list\\."]]
|
|
|
|
gdb_test_multiple "$cmd" "continue to end" {
|
|
-re "$\r\n${gdb_prompt} .*${msg_re}\r\n" {
|
|
pass $gdb_test_name
|
|
}
|
|
-re "\r\n${msg_re}\r\n.*$gdb_prompt " {
|
|
pass $gdb_test_name
|
|
}
|
|
}
|
|
|
|
set test "thread-specific breakpoint was deleted"
|
|
gdb_test_multiple "info breakpoint" $test {
|
|
-re "thread $start_thre\n$gdb_prompt $" {
|
|
fail $test
|
|
}
|
|
-re "$gdb_prompt $" {
|
|
pass $test
|
|
}
|
|
}
|
|
}
|
|
|
|
foreach_with_prefix non_stop {on off} {
|
|
save_vars { GDBFLAGS } {
|
|
append GDBFLAGS " -ex \"set non-stop $non_stop\""
|
|
clean_restart $binfile
|
|
}
|
|
|
|
check_thread_specific_breakpoint $non_stop
|
|
}
|