4eec2deb06
On GNU/Linux, if the target reuses the TID of a thread that GDB still has in its list marked as THREAD_EXITED, GDB crashes, like: (gdb) continue Continuing. src/gdb/thread.c:789: internal-error: set_running: Assertion `tp->state != THREAD_EXITED' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) FAIL: gdb.threads/tid-reuse.exp: continue to breakpoint: after_reuse_time (GDB internal error) Here: (top-gdb) bt #0 internal_error (file=0x953dd8 "src/gdb/thread.c", line=789, fmt=0x953da0 "%s: Assertion `%s' failed.") at src/gdb/common/errors.c:54 #1 0x0000000000638514 in set_running (ptid=..., running=1) at src/gdb/thread.c:789 #2 0x00000000004bda42 in linux_handle_extended_wait (lp=0x16f5760, status=0, stopping=0) at src/gdb/linux-nat.c:2114 #3 0x00000000004bfa24 in linux_nat_filter_event (lwpid=20570, status=198015) at src/gdb/linux-nat.c:3127 #4 0x00000000004c070e in linux_nat_wait_1 (ops=0xe193d0, ptid=..., ourstatus=0x7fffffffd2c0, target_options=1) at src/gdb/linux-nat.c:3478 #5 0x00000000004c1015 in linux_nat_wait (ops=0xe193d0, ptid=..., ourstatus=0x7fffffffd2c0, target_options=1) at src/gdb/linux-nat.c:3722 #6 0x00000000004c92d2 in thread_db_wait (ops=0xd80b60 <thread_db_ops>, ptid=..., ourstatus=0x7fffffffd2c0, options=1) at src/gdb/linux-thread-db.c:1525 #7 0x000000000066db43 in delegate_wait (self=0xd80b60 <thread_db_ops>, arg1=..., arg2=0x7fffffffd2c0, arg3=1) at src/gdb/target-delegates.c:116 #8 0x000000000067e54b in target_wait (ptid=..., status=0x7fffffffd2c0, options=1) at src/gdb/target.c:2206 #9 0x0000000000625111 in fetch_inferior_event (client_data=0x0) at src/gdb/infrun.c:3275 #10 0x0000000000648a3b in inferior_event_handler (event_type=INF_REG_EVENT, client_data=0x0) at src/gdb/inf-loop.c:56 #11 0x00000000004c2ecb in handle_target_event (error=0, client_data=0x0) at src/gdb/linux-nat.c:4655 I managed to come up with a test that reliably reproduces this. It spawns enough threads for the pid number space to wrap around, so could potentially take a while. On my box that's 4 seconds; on gcc110, a PPC box which has max_pid set to 65536, it's over 10 seconds. So I made the test compute how long that would take, and cap the time waited if it would be unreasonably long. Tested on x86_64 Fedora 20. gdb/ChangeLog: 2015-04-01 Pedro Alves <palves@redhat.com> * linux-thread-db.c (record_thread): Readd the thread to gdb's list if it was marked exited. gdb/testsuite/ChangeLog: 2015-04-01 Pedro Alves <palves@redhat.com> * gdb.threads/tid-reuse.c: New file. * gdb.threads/tid-reuse.exp: New file.
80 lines
2.5 KiB
Text
80 lines
2.5 KiB
Text
# Copyright 2015 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/>.
|
|
|
|
# Test running a program that spawns enough threads that the tid of an
|
|
# exited thread is reused. GDB should not crash when this happens.
|
|
|
|
standard_testfile
|
|
|
|
if {[prepare_for_testing "failed to prepare" $testfile $srcfile { debug pthreads }] == -1} {
|
|
return -1
|
|
}
|
|
|
|
clean_restart ${binfile}
|
|
|
|
if ![runto main] {
|
|
fail "Can't run to main"
|
|
return -1
|
|
}
|
|
|
|
delete_breakpoints
|
|
|
|
# Avoid dumping a ton of thread create/exit info in the logs.
|
|
gdb_test_no_output "set print thread-events off"
|
|
|
|
gdb_breakpoint "after_count"
|
|
gdb_continue_to_breakpoint "after_count"
|
|
|
|
# Get value of VARIABLE in the inferior.
|
|
|
|
proc getvar {variable} {
|
|
global decimal
|
|
global gdb_prompt
|
|
|
|
set value 0
|
|
|
|
set msg "get $variable"
|
|
gdb_test_multiple "print $variable" $msg {
|
|
-re " = ($decimal)\r\n$gdb_prompt $" {
|
|
set value $expect_out(1,string)
|
|
pass $msg
|
|
}
|
|
}
|
|
return $value
|
|
}
|
|
|
|
set reuse_time [getvar "reuse_time"]
|
|
|
|
# Now the real test. Run to a breakpoint in a thread that exits
|
|
# immediately once resumed. The thread ends up left on the thread
|
|
# list, marked exited (exactly because it's the selected thread).
|
|
gdb_breakpoint "do_nothing_thread_func"
|
|
gdb_continue_to_breakpoint "do_nothing_thread_func"
|
|
|
|
delete_breakpoints
|
|
|
|
# Let the program continue, constantly spawning short-lived threads
|
|
# (one at a time). On some targets, after a bit, a new thread reuses
|
|
# the tid of the old exited thread that we still have selected. GDB
|
|
# should not crash in this situation. Of course, if the tid number
|
|
# space is shared between all processes in the system (such as on
|
|
# Linux), there's a chance that some other process grabs the TID, but
|
|
# that can never cause a spurious test fail.
|
|
gdb_breakpoint "after_reuse_time"
|
|
|
|
# Higher than what the test program sleeps before exiting.
|
|
set timeout [expr $reuse_time * 2]
|
|
|
|
gdb_continue_to_breakpoint "after_reuse_time"
|