binutils-gdb/gdb/testsuite/gdb.multi/multi-kill.exp

138 lines
3.6 KiB
Plaintext
Raw Normal View History

gdb/infrun: handle already-exited threads when attempting to stop In stop_all_threads, GDB sends signals to other threads in an attempt to stop them. While in a typical scenario the expected wait status is TARGET_WAITKIND_STOPPED, it is possible that the thread GDB attempted to stop has already terminated. If so, a waitstatus other than TARGET_WAITKIND_STOPPED would be received. Handle this case appropriately. If a wait status that denotes thread termination is ignored, GDB goes into an infinite loop in stop_all_threads. E.g.: $ gdb ./a.out (gdb) start ... (gdb) add-inferior -exec ./a.out ... (gdb) inferior 2 ... (gdb) start ... (gdb) set schedule-multiple on (gdb) set debug infrun 2 (gdb) continue Continuing. infrun: clear_proceed_status_thread (process 10449) infrun: clear_proceed_status_thread (process 10453) infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT) infrun: proceed: resuming process 10449 infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 10449] at 0x55555555514e infrun: infrun_async(1) infrun: prepare_to_wait infrun: proceed: resuming process 10453 infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 10453] at 0x55555555514e infrun: prepare_to_wait infrun: Found 2 inferiors, starting at #0 infrun: target_wait (-1.0.0, status) = infrun: 10449.10449.0 [process 10449], infrun: status->kind = exited, status = 0 infrun: handle_inferior_event status->kind = exited, status = 0 [Inferior 1 (process 10449) exited normally] infrun: stop_waiting infrun: stop_all_threads infrun: stop_all_threads, pass=0, iterations=0 infrun: process 10453 executing, need stop infrun: target_wait (-1.0.0, status) = infrun: 10453.10453.0 [process 10453], infrun: status->kind = exited, status = 0 infrun: stop_all_threads status->kind = exited, status = 0 process 10453 infrun: process 10453 executing, already stopping infrun: target_wait (-1.0.0, status) = infrun: -1.0.0 [process -1], infrun: status->kind = no-resumed infrun: infrun_async(0) infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping ... And this polling goes on forever. This patch prevents the infinite looping behavior. For the same scenario above, we obtain the following behavior: ... (gdb) continue Continuing. infrun: clear_proceed_status_thread (process 31229) infrun: clear_proceed_status_thread (process 31233) infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT) infrun: proceed: resuming process 31229 infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 31229] at 0x55555555514e infrun: infrun_async(1) infrun: prepare_to_wait infrun: proceed: resuming process 31233 infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 31233] at 0x55555555514e infrun: prepare_to_wait infrun: Found 2 inferiors, starting at #0 infrun: target_wait (-1.0.0, status) = infrun: 31229.31229.0 [process 31229], infrun: status->kind = exited, status = 0 infrun: handle_inferior_event status->kind = exited, status = 0 [Inferior 1 (process 31229) exited normally] infrun: stop_waiting infrun: stop_all_threads infrun: stop_all_threads, pass=0, iterations=0 infrun: process 31233 executing, need stop infrun: target_wait (-1.0.0, status) = infrun: 31233.31233.0 [process 31233], infrun: status->kind = exited, status = 0 infrun: stop_all_threads status->kind = exited, status = 0 process 31233 infrun: saving status status->kind = exited, status = 0 for 31233.31233.0 infrun: process 31233 not executing infrun: stop_all_threads, pass=1, iterations=1 infrun: process 31233 not executing infrun: stop_all_threads done (gdb) The exit event from Inferior 1 is received and shown to the user. The exit event from Inferior 2 is not displayed, but kept pending. (gdb) info inferiors Num Description Connection Executable * 1 <null> a.out 2 process 31233 1 (native) a.out (gdb) inferior 2 [Switching to inferior 2 [process 31233] (a.out)] [Switching to thread 2.1 (process 31233)] Couldn't get registers: No such process. (gdb) continue Continuing. infrun: clear_proceed_status_thread (process 31233) infrun: clear_proceed_status_thread: thread process 31233 has pending wait status status->kind = exited, status = 0 (currently_stepping=0). infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT) infrun: proceed: resuming process 31233 infrun: resume: thread process 31233 has pending wait status status->kind = exited, status = 0 (currently_stepping=0). infrun: prepare_to_wait infrun: Using pending wait status status->kind = exited, status = 0 for process 31233. infrun: target_wait (-1.0.0, status) = infrun: 31233.31233.0 [process 31233], infrun: status->kind = exited, status = 0 infrun: handle_inferior_event status->kind = exited, status = 0 [Inferior 2 (process 31233) exited normally] infrun: stop_waiting (gdb) info inferiors Num Description Connection Executable 1 <null> a.out * 2 <null> a.out (gdb) When a process exits and we leave the process exit event pending, we need to make sure that at least one thread is left listed in the inferior's thread list. This is necessary in order to make sure we have a thread that we can later resume, so the process exit event can be collected/reported. When native debugging, the GNU/Linux back end already makes sure that the last LWP isn't deleted. When remote debugging against GNU/Linux GDBserver, the GNU/Linux GDBserver backend also makes sure that the last thread isn't deleted until the process exit event is reported to GDBserver core. However, between the backend reporting the process exit event to GDBserver core, and GDB consuming the event, GDB may update the thread list and find no thread left in the process. The process exit event will be pending somewhere in GDBserver's stop reply queue, or gdb/remote.c's queue, or whathever other event queue inbetween GDBserver and infrun.c's handle_inferior_event. This patch tweaks remote.c's target_update_thread_list implementation to avoid deleting the last thread of an inferior. In the past, this case of inferior-with-no-threads led to a special case at the bottom of handle_no_resumed, where it reads: /* Note however that we may find no resumed thread because the whole process exited meanwhile (thus updating the thread list results in an empty thread list). In this case we know we'll be getting a process exit event shortly. */ for (inferior *inf : all_non_exited_inferiors (ecs->target)) In current master, that code path is still reachable with the gdb.threads/continue-pending-after-query.exp testcase, when tested against GDBserver, with "maint set target-non-stop" forced "on". With this patch, the scenario that loop was concerned about is still properly handled, because the loop above it finds the process's last thread with "executing" set to true, and thus the handle_no_resumed function still returns true. Since GNU/Linux native and remote are the only targets that support non-stop mode, and with this patch, we always make sure the inferior has at least one thread, this patch also removes that "inferior with no threads" special case handling from handle_no_resumed. Since remote.c now has a special case where we treat a thread that has already exited as if it was still alive, we might need to tweak remote.c's target_thread_alive implementation to return true for that thread without querying the remote side (which would say "no, not alive"). After inspecting all the target_thread_alive calls in the codebase, it seems that only the one from prune_threads could result in that thread being accidentally deleted. There's only one call to prune_threads in GDB's common code, so this patch handles this by replacing the prune_threads call with a delete_exited_threads call. This seems like an improvement anyway, because we'll still be doing what the comment suggests we want to do, and, we avoid remote protocol traffic. Regression-tested on X86_64 Linux. gdb/ChangeLog: 2020-05-14 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> Tom de Vries <tdevries@suse.de> Pedro Alves <palves@redhat.com> PR threads/25478 * infrun.c (stop_all_threads): Do NOT ignore TARGET_WAITKIND_NO_RESUMED, TARGET_WAITKIND_THREAD_EXITED, TARGET_WAITKIND_EXITED, TARGET_WAITKIND_SIGNALLED wait statuses received. (handle_no_resumed): Remove code handling a live inferior with no threads. * remote.c (has_single_non_exited_thread): New. (remote_target::update_thread_list): Do not delete a thread if is the last thread of the process. * thread.c (thread_select): Call delete_exited_threads instead of prune_threads. gdb/testsuite/ChangeLog: 2020-05-14 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> Pedro Alves <palves@redhat.com> * gdb.multi/multi-exit.c: New file. * gdb.multi/multi-exit.exp: New file. * gdb.multi/multi-kill.c: New file. * gdb.multi/multi-kill.exp: New file.
2020-05-14 13:59:54 +02:00
# This testcase is part of GDB, the GNU debugger.
# Copyright 2020 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 receiving TARGET_WAITKIND_SIGNALLED events from multiple
# inferiors. In all stop-mode, upon receiving the exit event from one
# of the inferiors, GDB will try to stop the other inferior, too. So,
# a stop request will be sent. Receiving a TARGET_WAITKIND_SIGNALLED
# status kind as a response to that stop request instead of a
# TARGET_WAITKIND_STOPPED should be handled by GDB without problems.
standard_testfile
if {[use_gdb_stub]} {
return 0
}
if {[build_executable "failed to prepare" $testfile $srcfile {debug}]} {
return -1
}
# We are testing GDB's ability to stop all threads.
# Hence, go with the all-stop-on-top-of-non-stop mode.
save_vars { GDBFLAGS } {
append GDBFLAGS " -ex \"maint set target-non-stop on\""
clean_restart ${binfile}
}
# Wrap the entire test in a namespace to avoid contaminating other tests.
namespace eval $testfile {
gdb/infrun: handle already-exited threads when attempting to stop In stop_all_threads, GDB sends signals to other threads in an attempt to stop them. While in a typical scenario the expected wait status is TARGET_WAITKIND_STOPPED, it is possible that the thread GDB attempted to stop has already terminated. If so, a waitstatus other than TARGET_WAITKIND_STOPPED would be received. Handle this case appropriately. If a wait status that denotes thread termination is ignored, GDB goes into an infinite loop in stop_all_threads. E.g.: $ gdb ./a.out (gdb) start ... (gdb) add-inferior -exec ./a.out ... (gdb) inferior 2 ... (gdb) start ... (gdb) set schedule-multiple on (gdb) set debug infrun 2 (gdb) continue Continuing. infrun: clear_proceed_status_thread (process 10449) infrun: clear_proceed_status_thread (process 10453) infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT) infrun: proceed: resuming process 10449 infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 10449] at 0x55555555514e infrun: infrun_async(1) infrun: prepare_to_wait infrun: proceed: resuming process 10453 infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 10453] at 0x55555555514e infrun: prepare_to_wait infrun: Found 2 inferiors, starting at #0 infrun: target_wait (-1.0.0, status) = infrun: 10449.10449.0 [process 10449], infrun: status->kind = exited, status = 0 infrun: handle_inferior_event status->kind = exited, status = 0 [Inferior 1 (process 10449) exited normally] infrun: stop_waiting infrun: stop_all_threads infrun: stop_all_threads, pass=0, iterations=0 infrun: process 10453 executing, need stop infrun: target_wait (-1.0.0, status) = infrun: 10453.10453.0 [process 10453], infrun: status->kind = exited, status = 0 infrun: stop_all_threads status->kind = exited, status = 0 process 10453 infrun: process 10453 executing, already stopping infrun: target_wait (-1.0.0, status) = infrun: -1.0.0 [process -1], infrun: status->kind = no-resumed infrun: infrun_async(0) infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping ... And this polling goes on forever. This patch prevents the infinite looping behavior. For the same scenario above, we obtain the following behavior: ... (gdb) continue Continuing. infrun: clear_proceed_status_thread (process 31229) infrun: clear_proceed_status_thread (process 31233) infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT) infrun: proceed: resuming process 31229 infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 31229] at 0x55555555514e infrun: infrun_async(1) infrun: prepare_to_wait infrun: proceed: resuming process 31233 infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 31233] at 0x55555555514e infrun: prepare_to_wait infrun: Found 2 inferiors, starting at #0 infrun: target_wait (-1.0.0, status) = infrun: 31229.31229.0 [process 31229], infrun: status->kind = exited, status = 0 infrun: handle_inferior_event status->kind = exited, status = 0 [Inferior 1 (process 31229) exited normally] infrun: stop_waiting infrun: stop_all_threads infrun: stop_all_threads, pass=0, iterations=0 infrun: process 31233 executing, need stop infrun: target_wait (-1.0.0, status) = infrun: 31233.31233.0 [process 31233], infrun: status->kind = exited, status = 0 infrun: stop_all_threads status->kind = exited, status = 0 process 31233 infrun: saving status status->kind = exited, status = 0 for 31233.31233.0 infrun: process 31233 not executing infrun: stop_all_threads, pass=1, iterations=1 infrun: process 31233 not executing infrun: stop_all_threads done (gdb) The exit event from Inferior 1 is received and shown to the user. The exit event from Inferior 2 is not displayed, but kept pending. (gdb) info inferiors Num Description Connection Executable * 1 <null> a.out 2 process 31233 1 (native) a.out (gdb) inferior 2 [Switching to inferior 2 [process 31233] (a.out)] [Switching to thread 2.1 (process 31233)] Couldn't get registers: No such process. (gdb) continue Continuing. infrun: clear_proceed_status_thread (process 31233) infrun: clear_proceed_status_thread: thread process 31233 has pending wait status status->kind = exited, status = 0 (currently_stepping=0). infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT) infrun: proceed: resuming process 31233 infrun: resume: thread process 31233 has pending wait status status->kind = exited, status = 0 (currently_stepping=0). infrun: prepare_to_wait infrun: Using pending wait status status->kind = exited, status = 0 for process 31233. infrun: target_wait (-1.0.0, status) = infrun: 31233.31233.0 [process 31233], infrun: status->kind = exited, status = 0 infrun: handle_inferior_event status->kind = exited, status = 0 [Inferior 2 (process 31233) exited normally] infrun: stop_waiting (gdb) info inferiors Num Description Connection Executable 1 <null> a.out * 2 <null> a.out (gdb) When a process exits and we leave the process exit event pending, we need to make sure that at least one thread is left listed in the inferior's thread list. This is necessary in order to make sure we have a thread that we can later resume, so the process exit event can be collected/reported. When native debugging, the GNU/Linux back end already makes sure that the last LWP isn't deleted. When remote debugging against GNU/Linux GDBserver, the GNU/Linux GDBserver backend also makes sure that the last thread isn't deleted until the process exit event is reported to GDBserver core. However, between the backend reporting the process exit event to GDBserver core, and GDB consuming the event, GDB may update the thread list and find no thread left in the process. The process exit event will be pending somewhere in GDBserver's stop reply queue, or gdb/remote.c's queue, or whathever other event queue inbetween GDBserver and infrun.c's handle_inferior_event. This patch tweaks remote.c's target_update_thread_list implementation to avoid deleting the last thread of an inferior. In the past, this case of inferior-with-no-threads led to a special case at the bottom of handle_no_resumed, where it reads: /* Note however that we may find no resumed thread because the whole process exited meanwhile (thus updating the thread list results in an empty thread list). In this case we know we'll be getting a process exit event shortly. */ for (inferior *inf : all_non_exited_inferiors (ecs->target)) In current master, that code path is still reachable with the gdb.threads/continue-pending-after-query.exp testcase, when tested against GDBserver, with "maint set target-non-stop" forced "on". With this patch, the scenario that loop was concerned about is still properly handled, because the loop above it finds the process's last thread with "executing" set to true, and thus the handle_no_resumed function still returns true. Since GNU/Linux native and remote are the only targets that support non-stop mode, and with this patch, we always make sure the inferior has at least one thread, this patch also removes that "inferior with no threads" special case handling from handle_no_resumed. Since remote.c now has a special case where we treat a thread that has already exited as if it was still alive, we might need to tweak remote.c's target_thread_alive implementation to return true for that thread without querying the remote side (which would say "no, not alive"). After inspecting all the target_thread_alive calls in the codebase, it seems that only the one from prune_threads could result in that thread being accidentally deleted. There's only one call to prune_threads in GDB's common code, so this patch handles this by replacing the prune_threads call with a delete_exited_threads call. This seems like an improvement anyway, because we'll still be doing what the comment suggests we want to do, and, we avoid remote protocol traffic. Regression-tested on X86_64 Linux. gdb/ChangeLog: 2020-05-14 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> Tom de Vries <tdevries@suse.de> Pedro Alves <palves@redhat.com> PR threads/25478 * infrun.c (stop_all_threads): Do NOT ignore TARGET_WAITKIND_NO_RESUMED, TARGET_WAITKIND_THREAD_EXITED, TARGET_WAITKIND_EXITED, TARGET_WAITKIND_SIGNALLED wait statuses received. (handle_no_resumed): Remove code handling a live inferior with no threads. * remote.c (has_single_non_exited_thread): New. (remote_target::update_thread_list): Do not delete a thread if is the last thread of the process. * thread.c (thread_select): Call delete_exited_threads instead of prune_threads. gdb/testsuite/ChangeLog: 2020-05-14 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> Pedro Alves <palves@redhat.com> * gdb.multi/multi-exit.c: New file. * gdb.multi/multi-exit.exp: New file. * gdb.multi/multi-kill.c: New file. * gdb.multi/multi-kill.exp: New file.
2020-05-14 13:59:54 +02:00
# Start inferior NUM and record its PID in the TESTPID array.
proc start_inferior {num} {
gdb/infrun: handle already-exited threads when attempting to stop In stop_all_threads, GDB sends signals to other threads in an attempt to stop them. While in a typical scenario the expected wait status is TARGET_WAITKIND_STOPPED, it is possible that the thread GDB attempted to stop has already terminated. If so, a waitstatus other than TARGET_WAITKIND_STOPPED would be received. Handle this case appropriately. If a wait status that denotes thread termination is ignored, GDB goes into an infinite loop in stop_all_threads. E.g.: $ gdb ./a.out (gdb) start ... (gdb) add-inferior -exec ./a.out ... (gdb) inferior 2 ... (gdb) start ... (gdb) set schedule-multiple on (gdb) set debug infrun 2 (gdb) continue Continuing. infrun: clear_proceed_status_thread (process 10449) infrun: clear_proceed_status_thread (process 10453) infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT) infrun: proceed: resuming process 10449 infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 10449] at 0x55555555514e infrun: infrun_async(1) infrun: prepare_to_wait infrun: proceed: resuming process 10453 infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 10453] at 0x55555555514e infrun: prepare_to_wait infrun: Found 2 inferiors, starting at #0 infrun: target_wait (-1.0.0, status) = infrun: 10449.10449.0 [process 10449], infrun: status->kind = exited, status = 0 infrun: handle_inferior_event status->kind = exited, status = 0 [Inferior 1 (process 10449) exited normally] infrun: stop_waiting infrun: stop_all_threads infrun: stop_all_threads, pass=0, iterations=0 infrun: process 10453 executing, need stop infrun: target_wait (-1.0.0, status) = infrun: 10453.10453.0 [process 10453], infrun: status->kind = exited, status = 0 infrun: stop_all_threads status->kind = exited, status = 0 process 10453 infrun: process 10453 executing, already stopping infrun: target_wait (-1.0.0, status) = infrun: -1.0.0 [process -1], infrun: status->kind = no-resumed infrun: infrun_async(0) infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping ... And this polling goes on forever. This patch prevents the infinite looping behavior. For the same scenario above, we obtain the following behavior: ... (gdb) continue Continuing. infrun: clear_proceed_status_thread (process 31229) infrun: clear_proceed_status_thread (process 31233) infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT) infrun: proceed: resuming process 31229 infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 31229] at 0x55555555514e infrun: infrun_async(1) infrun: prepare_to_wait infrun: proceed: resuming process 31233 infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 31233] at 0x55555555514e infrun: prepare_to_wait infrun: Found 2 inferiors, starting at #0 infrun: target_wait (-1.0.0, status) = infrun: 31229.31229.0 [process 31229], infrun: status->kind = exited, status = 0 infrun: handle_inferior_event status->kind = exited, status = 0 [Inferior 1 (process 31229) exited normally] infrun: stop_waiting infrun: stop_all_threads infrun: stop_all_threads, pass=0, iterations=0 infrun: process 31233 executing, need stop infrun: target_wait (-1.0.0, status) = infrun: 31233.31233.0 [process 31233], infrun: status->kind = exited, status = 0 infrun: stop_all_threads status->kind = exited, status = 0 process 31233 infrun: saving status status->kind = exited, status = 0 for 31233.31233.0 infrun: process 31233 not executing infrun: stop_all_threads, pass=1, iterations=1 infrun: process 31233 not executing infrun: stop_all_threads done (gdb) The exit event from Inferior 1 is received and shown to the user. The exit event from Inferior 2 is not displayed, but kept pending. (gdb) info inferiors Num Description Connection Executable * 1 <null> a.out 2 process 31233 1 (native) a.out (gdb) inferior 2 [Switching to inferior 2 [process 31233] (a.out)] [Switching to thread 2.1 (process 31233)] Couldn't get registers: No such process. (gdb) continue Continuing. infrun: clear_proceed_status_thread (process 31233) infrun: clear_proceed_status_thread: thread process 31233 has pending wait status status->kind = exited, status = 0 (currently_stepping=0). infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT) infrun: proceed: resuming process 31233 infrun: resume: thread process 31233 has pending wait status status->kind = exited, status = 0 (currently_stepping=0). infrun: prepare_to_wait infrun: Using pending wait status status->kind = exited, status = 0 for process 31233. infrun: target_wait (-1.0.0, status) = infrun: 31233.31233.0 [process 31233], infrun: status->kind = exited, status = 0 infrun: handle_inferior_event status->kind = exited, status = 0 [Inferior 2 (process 31233) exited normally] infrun: stop_waiting (gdb) info inferiors Num Description Connection Executable 1 <null> a.out * 2 <null> a.out (gdb) When a process exits and we leave the process exit event pending, we need to make sure that at least one thread is left listed in the inferior's thread list. This is necessary in order to make sure we have a thread that we can later resume, so the process exit event can be collected/reported. When native debugging, the GNU/Linux back end already makes sure that the last LWP isn't deleted. When remote debugging against GNU/Linux GDBserver, the GNU/Linux GDBserver backend also makes sure that the last thread isn't deleted until the process exit event is reported to GDBserver core. However, between the backend reporting the process exit event to GDBserver core, and GDB consuming the event, GDB may update the thread list and find no thread left in the process. The process exit event will be pending somewhere in GDBserver's stop reply queue, or gdb/remote.c's queue, or whathever other event queue inbetween GDBserver and infrun.c's handle_inferior_event. This patch tweaks remote.c's target_update_thread_list implementation to avoid deleting the last thread of an inferior. In the past, this case of inferior-with-no-threads led to a special case at the bottom of handle_no_resumed, where it reads: /* Note however that we may find no resumed thread because the whole process exited meanwhile (thus updating the thread list results in an empty thread list). In this case we know we'll be getting a process exit event shortly. */ for (inferior *inf : all_non_exited_inferiors (ecs->target)) In current master, that code path is still reachable with the gdb.threads/continue-pending-after-query.exp testcase, when tested against GDBserver, with "maint set target-non-stop" forced "on". With this patch, the scenario that loop was concerned about is still properly handled, because the loop above it finds the process's last thread with "executing" set to true, and thus the handle_no_resumed function still returns true. Since GNU/Linux native and remote are the only targets that support non-stop mode, and with this patch, we always make sure the inferior has at least one thread, this patch also removes that "inferior with no threads" special case handling from handle_no_resumed. Since remote.c now has a special case where we treat a thread that has already exited as if it was still alive, we might need to tweak remote.c's target_thread_alive implementation to return true for that thread without querying the remote side (which would say "no, not alive"). After inspecting all the target_thread_alive calls in the codebase, it seems that only the one from prune_threads could result in that thread being accidentally deleted. There's only one call to prune_threads in GDB's common code, so this patch handles this by replacing the prune_threads call with a delete_exited_threads call. This seems like an improvement anyway, because we'll still be doing what the comment suggests we want to do, and, we avoid remote protocol traffic. Regression-tested on X86_64 Linux. gdb/ChangeLog: 2020-05-14 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> Tom de Vries <tdevries@suse.de> Pedro Alves <palves@redhat.com> PR threads/25478 * infrun.c (stop_all_threads): Do NOT ignore TARGET_WAITKIND_NO_RESUMED, TARGET_WAITKIND_THREAD_EXITED, TARGET_WAITKIND_EXITED, TARGET_WAITKIND_SIGNALLED wait statuses received. (handle_no_resumed): Remove code handling a live inferior with no threads. * remote.c (has_single_non_exited_thread): New. (remote_target::update_thread_list): Do not delete a thread if is the last thread of the process. * thread.c (thread_select): Call delete_exited_threads instead of prune_threads. gdb/testsuite/ChangeLog: 2020-05-14 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> Pedro Alves <palves@redhat.com> * gdb.multi/multi-exit.c: New file. * gdb.multi/multi-exit.exp: New file. * gdb.multi/multi-kill.c: New file. * gdb.multi/multi-kill.exp: New file.
2020-05-14 13:59:54 +02:00
with_test_prefix "start_inferior $num" {
variable testpid
global binfile srcfile
gdb/infrun: handle already-exited threads when attempting to stop In stop_all_threads, GDB sends signals to other threads in an attempt to stop them. While in a typical scenario the expected wait status is TARGET_WAITKIND_STOPPED, it is possible that the thread GDB attempted to stop has already terminated. If so, a waitstatus other than TARGET_WAITKIND_STOPPED would be received. Handle this case appropriately. If a wait status that denotes thread termination is ignored, GDB goes into an infinite loop in stop_all_threads. E.g.: $ gdb ./a.out (gdb) start ... (gdb) add-inferior -exec ./a.out ... (gdb) inferior 2 ... (gdb) start ... (gdb) set schedule-multiple on (gdb) set debug infrun 2 (gdb) continue Continuing. infrun: clear_proceed_status_thread (process 10449) infrun: clear_proceed_status_thread (process 10453) infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT) infrun: proceed: resuming process 10449 infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 10449] at 0x55555555514e infrun: infrun_async(1) infrun: prepare_to_wait infrun: proceed: resuming process 10453 infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 10453] at 0x55555555514e infrun: prepare_to_wait infrun: Found 2 inferiors, starting at #0 infrun: target_wait (-1.0.0, status) = infrun: 10449.10449.0 [process 10449], infrun: status->kind = exited, status = 0 infrun: handle_inferior_event status->kind = exited, status = 0 [Inferior 1 (process 10449) exited normally] infrun: stop_waiting infrun: stop_all_threads infrun: stop_all_threads, pass=0, iterations=0 infrun: process 10453 executing, need stop infrun: target_wait (-1.0.0, status) = infrun: 10453.10453.0 [process 10453], infrun: status->kind = exited, status = 0 infrun: stop_all_threads status->kind = exited, status = 0 process 10453 infrun: process 10453 executing, already stopping infrun: target_wait (-1.0.0, status) = infrun: -1.0.0 [process -1], infrun: status->kind = no-resumed infrun: infrun_async(0) infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping ... And this polling goes on forever. This patch prevents the infinite looping behavior. For the same scenario above, we obtain the following behavior: ... (gdb) continue Continuing. infrun: clear_proceed_status_thread (process 31229) infrun: clear_proceed_status_thread (process 31233) infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT) infrun: proceed: resuming process 31229 infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 31229] at 0x55555555514e infrun: infrun_async(1) infrun: prepare_to_wait infrun: proceed: resuming process 31233 infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 31233] at 0x55555555514e infrun: prepare_to_wait infrun: Found 2 inferiors, starting at #0 infrun: target_wait (-1.0.0, status) = infrun: 31229.31229.0 [process 31229], infrun: status->kind = exited, status = 0 infrun: handle_inferior_event status->kind = exited, status = 0 [Inferior 1 (process 31229) exited normally] infrun: stop_waiting infrun: stop_all_threads infrun: stop_all_threads, pass=0, iterations=0 infrun: process 31233 executing, need stop infrun: target_wait (-1.0.0, status) = infrun: 31233.31233.0 [process 31233], infrun: status->kind = exited, status = 0 infrun: stop_all_threads status->kind = exited, status = 0 process 31233 infrun: saving status status->kind = exited, status = 0 for 31233.31233.0 infrun: process 31233 not executing infrun: stop_all_threads, pass=1, iterations=1 infrun: process 31233 not executing infrun: stop_all_threads done (gdb) The exit event from Inferior 1 is received and shown to the user. The exit event from Inferior 2 is not displayed, but kept pending. (gdb) info inferiors Num Description Connection Executable * 1 <null> a.out 2 process 31233 1 (native) a.out (gdb) inferior 2 [Switching to inferior 2 [process 31233] (a.out)] [Switching to thread 2.1 (process 31233)] Couldn't get registers: No such process. (gdb) continue Continuing. infrun: clear_proceed_status_thread (process 31233) infrun: clear_proceed_status_thread: thread process 31233 has pending wait status status->kind = exited, status = 0 (currently_stepping=0). infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT) infrun: proceed: resuming process 31233 infrun: resume: thread process 31233 has pending wait status status->kind = exited, status = 0 (currently_stepping=0). infrun: prepare_to_wait infrun: Using pending wait status status->kind = exited, status = 0 for process 31233. infrun: target_wait (-1.0.0, status) = infrun: 31233.31233.0 [process 31233], infrun: status->kind = exited, status = 0 infrun: handle_inferior_event status->kind = exited, status = 0 [Inferior 2 (process 31233) exited normally] infrun: stop_waiting (gdb) info inferiors Num Description Connection Executable 1 <null> a.out * 2 <null> a.out (gdb) When a process exits and we leave the process exit event pending, we need to make sure that at least one thread is left listed in the inferior's thread list. This is necessary in order to make sure we have a thread that we can later resume, so the process exit event can be collected/reported. When native debugging, the GNU/Linux back end already makes sure that the last LWP isn't deleted. When remote debugging against GNU/Linux GDBserver, the GNU/Linux GDBserver backend also makes sure that the last thread isn't deleted until the process exit event is reported to GDBserver core. However, between the backend reporting the process exit event to GDBserver core, and GDB consuming the event, GDB may update the thread list and find no thread left in the process. The process exit event will be pending somewhere in GDBserver's stop reply queue, or gdb/remote.c's queue, or whathever other event queue inbetween GDBserver and infrun.c's handle_inferior_event. This patch tweaks remote.c's target_update_thread_list implementation to avoid deleting the last thread of an inferior. In the past, this case of inferior-with-no-threads led to a special case at the bottom of handle_no_resumed, where it reads: /* Note however that we may find no resumed thread because the whole process exited meanwhile (thus updating the thread list results in an empty thread list). In this case we know we'll be getting a process exit event shortly. */ for (inferior *inf : all_non_exited_inferiors (ecs->target)) In current master, that code path is still reachable with the gdb.threads/continue-pending-after-query.exp testcase, when tested against GDBserver, with "maint set target-non-stop" forced "on". With this patch, the scenario that loop was concerned about is still properly handled, because the loop above it finds the process's last thread with "executing" set to true, and thus the handle_no_resumed function still returns true. Since GNU/Linux native and remote are the only targets that support non-stop mode, and with this patch, we always make sure the inferior has at least one thread, this patch also removes that "inferior with no threads" special case handling from handle_no_resumed. Since remote.c now has a special case where we treat a thread that has already exited as if it was still alive, we might need to tweak remote.c's target_thread_alive implementation to return true for that thread without querying the remote side (which would say "no, not alive"). After inspecting all the target_thread_alive calls in the codebase, it seems that only the one from prune_threads could result in that thread being accidentally deleted. There's only one call to prune_threads in GDB's common code, so this patch handles this by replacing the prune_threads call with a delete_exited_threads call. This seems like an improvement anyway, because we'll still be doing what the comment suggests we want to do, and, we avoid remote protocol traffic. Regression-tested on X86_64 Linux. gdb/ChangeLog: 2020-05-14 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> Tom de Vries <tdevries@suse.de> Pedro Alves <palves@redhat.com> PR threads/25478 * infrun.c (stop_all_threads): Do NOT ignore TARGET_WAITKIND_NO_RESUMED, TARGET_WAITKIND_THREAD_EXITED, TARGET_WAITKIND_EXITED, TARGET_WAITKIND_SIGNALLED wait statuses received. (handle_no_resumed): Remove code handling a live inferior with no threads. * remote.c (has_single_non_exited_thread): New. (remote_target::update_thread_list): Do not delete a thread if is the last thread of the process. * thread.c (thread_select): Call delete_exited_threads instead of prune_threads. gdb/testsuite/ChangeLog: 2020-05-14 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> Pedro Alves <palves@redhat.com> * gdb.multi/multi-exit.c: New file. * gdb.multi/multi-exit.exp: New file. * gdb.multi/multi-kill.c: New file. * gdb.multi/multi-kill.exp: New file.
2020-05-14 13:59:54 +02:00
if {$num != 1} {
gdb_test "add-inferior" "Added inferior .*" \
"add empty inferior"
gdb_test "inferior $num" "Switching to inferior .*" \
"switch to inferior"
}
gdb_load $binfile
gdb_breakpoint "initialized" {temporary}
gdb_run_cmd
gdb_test "" ".*reakpoint .*, initialized .*${srcfile}.*" "run"
set testpid($num) [get_integer_valueof "pid" -1]
if {$testpid($num) == -1} {
gdb/infrun: handle already-exited threads when attempting to stop In stop_all_threads, GDB sends signals to other threads in an attempt to stop them. While in a typical scenario the expected wait status is TARGET_WAITKIND_STOPPED, it is possible that the thread GDB attempted to stop has already terminated. If so, a waitstatus other than TARGET_WAITKIND_STOPPED would be received. Handle this case appropriately. If a wait status that denotes thread termination is ignored, GDB goes into an infinite loop in stop_all_threads. E.g.: $ gdb ./a.out (gdb) start ... (gdb) add-inferior -exec ./a.out ... (gdb) inferior 2 ... (gdb) start ... (gdb) set schedule-multiple on (gdb) set debug infrun 2 (gdb) continue Continuing. infrun: clear_proceed_status_thread (process 10449) infrun: clear_proceed_status_thread (process 10453) infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT) infrun: proceed: resuming process 10449 infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 10449] at 0x55555555514e infrun: infrun_async(1) infrun: prepare_to_wait infrun: proceed: resuming process 10453 infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 10453] at 0x55555555514e infrun: prepare_to_wait infrun: Found 2 inferiors, starting at #0 infrun: target_wait (-1.0.0, status) = infrun: 10449.10449.0 [process 10449], infrun: status->kind = exited, status = 0 infrun: handle_inferior_event status->kind = exited, status = 0 [Inferior 1 (process 10449) exited normally] infrun: stop_waiting infrun: stop_all_threads infrun: stop_all_threads, pass=0, iterations=0 infrun: process 10453 executing, need stop infrun: target_wait (-1.0.0, status) = infrun: 10453.10453.0 [process 10453], infrun: status->kind = exited, status = 0 infrun: stop_all_threads status->kind = exited, status = 0 process 10453 infrun: process 10453 executing, already stopping infrun: target_wait (-1.0.0, status) = infrun: -1.0.0 [process -1], infrun: status->kind = no-resumed infrun: infrun_async(0) infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping ... And this polling goes on forever. This patch prevents the infinite looping behavior. For the same scenario above, we obtain the following behavior: ... (gdb) continue Continuing. infrun: clear_proceed_status_thread (process 31229) infrun: clear_proceed_status_thread (process 31233) infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT) infrun: proceed: resuming process 31229 infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 31229] at 0x55555555514e infrun: infrun_async(1) infrun: prepare_to_wait infrun: proceed: resuming process 31233 infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 31233] at 0x55555555514e infrun: prepare_to_wait infrun: Found 2 inferiors, starting at #0 infrun: target_wait (-1.0.0, status) = infrun: 31229.31229.0 [process 31229], infrun: status->kind = exited, status = 0 infrun: handle_inferior_event status->kind = exited, status = 0 [Inferior 1 (process 31229) exited normally] infrun: stop_waiting infrun: stop_all_threads infrun: stop_all_threads, pass=0, iterations=0 infrun: process 31233 executing, need stop infrun: target_wait (-1.0.0, status) = infrun: 31233.31233.0 [process 31233], infrun: status->kind = exited, status = 0 infrun: stop_all_threads status->kind = exited, status = 0 process 31233 infrun: saving status status->kind = exited, status = 0 for 31233.31233.0 infrun: process 31233 not executing infrun: stop_all_threads, pass=1, iterations=1 infrun: process 31233 not executing infrun: stop_all_threads done (gdb) The exit event from Inferior 1 is received and shown to the user. The exit event from Inferior 2 is not displayed, but kept pending. (gdb) info inferiors Num Description Connection Executable * 1 <null> a.out 2 process 31233 1 (native) a.out (gdb) inferior 2 [Switching to inferior 2 [process 31233] (a.out)] [Switching to thread 2.1 (process 31233)] Couldn't get registers: No such process. (gdb) continue Continuing. infrun: clear_proceed_status_thread (process 31233) infrun: clear_proceed_status_thread: thread process 31233 has pending wait status status->kind = exited, status = 0 (currently_stepping=0). infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT) infrun: proceed: resuming process 31233 infrun: resume: thread process 31233 has pending wait status status->kind = exited, status = 0 (currently_stepping=0). infrun: prepare_to_wait infrun: Using pending wait status status->kind = exited, status = 0 for process 31233. infrun: target_wait (-1.0.0, status) = infrun: 31233.31233.0 [process 31233], infrun: status->kind = exited, status = 0 infrun: handle_inferior_event status->kind = exited, status = 0 [Inferior 2 (process 31233) exited normally] infrun: stop_waiting (gdb) info inferiors Num Description Connection Executable 1 <null> a.out * 2 <null> a.out (gdb) When a process exits and we leave the process exit event pending, we need to make sure that at least one thread is left listed in the inferior's thread list. This is necessary in order to make sure we have a thread that we can later resume, so the process exit event can be collected/reported. When native debugging, the GNU/Linux back end already makes sure that the last LWP isn't deleted. When remote debugging against GNU/Linux GDBserver, the GNU/Linux GDBserver backend also makes sure that the last thread isn't deleted until the process exit event is reported to GDBserver core. However, between the backend reporting the process exit event to GDBserver core, and GDB consuming the event, GDB may update the thread list and find no thread left in the process. The process exit event will be pending somewhere in GDBserver's stop reply queue, or gdb/remote.c's queue, or whathever other event queue inbetween GDBserver and infrun.c's handle_inferior_event. This patch tweaks remote.c's target_update_thread_list implementation to avoid deleting the last thread of an inferior. In the past, this case of inferior-with-no-threads led to a special case at the bottom of handle_no_resumed, where it reads: /* Note however that we may find no resumed thread because the whole process exited meanwhile (thus updating the thread list results in an empty thread list). In this case we know we'll be getting a process exit event shortly. */ for (inferior *inf : all_non_exited_inferiors (ecs->target)) In current master, that code path is still reachable with the gdb.threads/continue-pending-after-query.exp testcase, when tested against GDBserver, with "maint set target-non-stop" forced "on". With this patch, the scenario that loop was concerned about is still properly handled, because the loop above it finds the process's last thread with "executing" set to true, and thus the handle_no_resumed function still returns true. Since GNU/Linux native and remote are the only targets that support non-stop mode, and with this patch, we always make sure the inferior has at least one thread, this patch also removes that "inferior with no threads" special case handling from handle_no_resumed. Since remote.c now has a special case where we treat a thread that has already exited as if it was still alive, we might need to tweak remote.c's target_thread_alive implementation to return true for that thread without querying the remote side (which would say "no, not alive"). After inspecting all the target_thread_alive calls in the codebase, it seems that only the one from prune_threads could result in that thread being accidentally deleted. There's only one call to prune_threads in GDB's common code, so this patch handles this by replacing the prune_threads call with a delete_exited_threads call. This seems like an improvement anyway, because we'll still be doing what the comment suggests we want to do, and, we avoid remote protocol traffic. Regression-tested on X86_64 Linux. gdb/ChangeLog: 2020-05-14 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> Tom de Vries <tdevries@suse.de> Pedro Alves <palves@redhat.com> PR threads/25478 * infrun.c (stop_all_threads): Do NOT ignore TARGET_WAITKIND_NO_RESUMED, TARGET_WAITKIND_THREAD_EXITED, TARGET_WAITKIND_EXITED, TARGET_WAITKIND_SIGNALLED wait statuses received. (handle_no_resumed): Remove code handling a live inferior with no threads. * remote.c (has_single_non_exited_thread): New. (remote_target::update_thread_list): Do not delete a thread if is the last thread of the process. * thread.c (thread_select): Call delete_exited_threads instead of prune_threads. gdb/testsuite/ChangeLog: 2020-05-14 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> Pedro Alves <palves@redhat.com> * gdb.multi/multi-exit.c: New file. * gdb.multi/multi-exit.exp: New file. * gdb.multi/multi-kill.c: New file. * gdb.multi/multi-kill.exp: New file.
2020-05-14 13:59:54 +02:00
return -1
}
return 0
}
}
# Sufficient inferiors to make sure that at least some other inferior
# is killed while we're handling a killed event.
set NUM_INFS 10
# The array holding each inferior's PID, indexed by inferior number.
variable testpid
array set testpid {}
gdb/infrun: handle already-exited threads when attempting to stop In stop_all_threads, GDB sends signals to other threads in an attempt to stop them. While in a typical scenario the expected wait status is TARGET_WAITKIND_STOPPED, it is possible that the thread GDB attempted to stop has already terminated. If so, a waitstatus other than TARGET_WAITKIND_STOPPED would be received. Handle this case appropriately. If a wait status that denotes thread termination is ignored, GDB goes into an infinite loop in stop_all_threads. E.g.: $ gdb ./a.out (gdb) start ... (gdb) add-inferior -exec ./a.out ... (gdb) inferior 2 ... (gdb) start ... (gdb) set schedule-multiple on (gdb) set debug infrun 2 (gdb) continue Continuing. infrun: clear_proceed_status_thread (process 10449) infrun: clear_proceed_status_thread (process 10453) infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT) infrun: proceed: resuming process 10449 infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 10449] at 0x55555555514e infrun: infrun_async(1) infrun: prepare_to_wait infrun: proceed: resuming process 10453 infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 10453] at 0x55555555514e infrun: prepare_to_wait infrun: Found 2 inferiors, starting at #0 infrun: target_wait (-1.0.0, status) = infrun: 10449.10449.0 [process 10449], infrun: status->kind = exited, status = 0 infrun: handle_inferior_event status->kind = exited, status = 0 [Inferior 1 (process 10449) exited normally] infrun: stop_waiting infrun: stop_all_threads infrun: stop_all_threads, pass=0, iterations=0 infrun: process 10453 executing, need stop infrun: target_wait (-1.0.0, status) = infrun: 10453.10453.0 [process 10453], infrun: status->kind = exited, status = 0 infrun: stop_all_threads status->kind = exited, status = 0 process 10453 infrun: process 10453 executing, already stopping infrun: target_wait (-1.0.0, status) = infrun: -1.0.0 [process -1], infrun: status->kind = no-resumed infrun: infrun_async(0) infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping ... And this polling goes on forever. This patch prevents the infinite looping behavior. For the same scenario above, we obtain the following behavior: ... (gdb) continue Continuing. infrun: clear_proceed_status_thread (process 31229) infrun: clear_proceed_status_thread (process 31233) infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT) infrun: proceed: resuming process 31229 infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 31229] at 0x55555555514e infrun: infrun_async(1) infrun: prepare_to_wait infrun: proceed: resuming process 31233 infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 31233] at 0x55555555514e infrun: prepare_to_wait infrun: Found 2 inferiors, starting at #0 infrun: target_wait (-1.0.0, status) = infrun: 31229.31229.0 [process 31229], infrun: status->kind = exited, status = 0 infrun: handle_inferior_event status->kind = exited, status = 0 [Inferior 1 (process 31229) exited normally] infrun: stop_waiting infrun: stop_all_threads infrun: stop_all_threads, pass=0, iterations=0 infrun: process 31233 executing, need stop infrun: target_wait (-1.0.0, status) = infrun: 31233.31233.0 [process 31233], infrun: status->kind = exited, status = 0 infrun: stop_all_threads status->kind = exited, status = 0 process 31233 infrun: saving status status->kind = exited, status = 0 for 31233.31233.0 infrun: process 31233 not executing infrun: stop_all_threads, pass=1, iterations=1 infrun: process 31233 not executing infrun: stop_all_threads done (gdb) The exit event from Inferior 1 is received and shown to the user. The exit event from Inferior 2 is not displayed, but kept pending. (gdb) info inferiors Num Description Connection Executable * 1 <null> a.out 2 process 31233 1 (native) a.out (gdb) inferior 2 [Switching to inferior 2 [process 31233] (a.out)] [Switching to thread 2.1 (process 31233)] Couldn't get registers: No such process. (gdb) continue Continuing. infrun: clear_proceed_status_thread (process 31233) infrun: clear_proceed_status_thread: thread process 31233 has pending wait status status->kind = exited, status = 0 (currently_stepping=0). infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT) infrun: proceed: resuming process 31233 infrun: resume: thread process 31233 has pending wait status status->kind = exited, status = 0 (currently_stepping=0). infrun: prepare_to_wait infrun: Using pending wait status status->kind = exited, status = 0 for process 31233. infrun: target_wait (-1.0.0, status) = infrun: 31233.31233.0 [process 31233], infrun: status->kind = exited, status = 0 infrun: handle_inferior_event status->kind = exited, status = 0 [Inferior 2 (process 31233) exited normally] infrun: stop_waiting (gdb) info inferiors Num Description Connection Executable 1 <null> a.out * 2 <null> a.out (gdb) When a process exits and we leave the process exit event pending, we need to make sure that at least one thread is left listed in the inferior's thread list. This is necessary in order to make sure we have a thread that we can later resume, so the process exit event can be collected/reported. When native debugging, the GNU/Linux back end already makes sure that the last LWP isn't deleted. When remote debugging against GNU/Linux GDBserver, the GNU/Linux GDBserver backend also makes sure that the last thread isn't deleted until the process exit event is reported to GDBserver core. However, between the backend reporting the process exit event to GDBserver core, and GDB consuming the event, GDB may update the thread list and find no thread left in the process. The process exit event will be pending somewhere in GDBserver's stop reply queue, or gdb/remote.c's queue, or whathever other event queue inbetween GDBserver and infrun.c's handle_inferior_event. This patch tweaks remote.c's target_update_thread_list implementation to avoid deleting the last thread of an inferior. In the past, this case of inferior-with-no-threads led to a special case at the bottom of handle_no_resumed, where it reads: /* Note however that we may find no resumed thread because the whole process exited meanwhile (thus updating the thread list results in an empty thread list). In this case we know we'll be getting a process exit event shortly. */ for (inferior *inf : all_non_exited_inferiors (ecs->target)) In current master, that code path is still reachable with the gdb.threads/continue-pending-after-query.exp testcase, when tested against GDBserver, with "maint set target-non-stop" forced "on". With this patch, the scenario that loop was concerned about is still properly handled, because the loop above it finds the process's last thread with "executing" set to true, and thus the handle_no_resumed function still returns true. Since GNU/Linux native and remote are the only targets that support non-stop mode, and with this patch, we always make sure the inferior has at least one thread, this patch also removes that "inferior with no threads" special case handling from handle_no_resumed. Since remote.c now has a special case where we treat a thread that has already exited as if it was still alive, we might need to tweak remote.c's target_thread_alive implementation to return true for that thread without querying the remote side (which would say "no, not alive"). After inspecting all the target_thread_alive calls in the codebase, it seems that only the one from prune_threads could result in that thread being accidentally deleted. There's only one call to prune_threads in GDB's common code, so this patch handles this by replacing the prune_threads call with a delete_exited_threads call. This seems like an improvement anyway, because we'll still be doing what the comment suggests we want to do, and, we avoid remote protocol traffic. Regression-tested on X86_64 Linux. gdb/ChangeLog: 2020-05-14 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> Tom de Vries <tdevries@suse.de> Pedro Alves <palves@redhat.com> PR threads/25478 * infrun.c (stop_all_threads): Do NOT ignore TARGET_WAITKIND_NO_RESUMED, TARGET_WAITKIND_THREAD_EXITED, TARGET_WAITKIND_EXITED, TARGET_WAITKIND_SIGNALLED wait statuses received. (handle_no_resumed): Remove code handling a live inferior with no threads. * remote.c (has_single_non_exited_thread): New. (remote_target::update_thread_list): Do not delete a thread if is the last thread of the process. * thread.c (thread_select): Call delete_exited_threads instead of prune_threads. gdb/testsuite/ChangeLog: 2020-05-14 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> Pedro Alves <palves@redhat.com> * gdb.multi/multi-exit.c: New file. * gdb.multi/multi-exit.exp: New file. * gdb.multi/multi-kill.c: New file. * gdb.multi/multi-kill.exp: New file.
2020-05-14 13:59:54 +02:00
for {set i 1} {$i <= $NUM_INFS} {incr i} {
if {[start_inferior $i] < 0} {
gdb/infrun: handle already-exited threads when attempting to stop In stop_all_threads, GDB sends signals to other threads in an attempt to stop them. While in a typical scenario the expected wait status is TARGET_WAITKIND_STOPPED, it is possible that the thread GDB attempted to stop has already terminated. If so, a waitstatus other than TARGET_WAITKIND_STOPPED would be received. Handle this case appropriately. If a wait status that denotes thread termination is ignored, GDB goes into an infinite loop in stop_all_threads. E.g.: $ gdb ./a.out (gdb) start ... (gdb) add-inferior -exec ./a.out ... (gdb) inferior 2 ... (gdb) start ... (gdb) set schedule-multiple on (gdb) set debug infrun 2 (gdb) continue Continuing. infrun: clear_proceed_status_thread (process 10449) infrun: clear_proceed_status_thread (process 10453) infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT) infrun: proceed: resuming process 10449 infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 10449] at 0x55555555514e infrun: infrun_async(1) infrun: prepare_to_wait infrun: proceed: resuming process 10453 infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 10453] at 0x55555555514e infrun: prepare_to_wait infrun: Found 2 inferiors, starting at #0 infrun: target_wait (-1.0.0, status) = infrun: 10449.10449.0 [process 10449], infrun: status->kind = exited, status = 0 infrun: handle_inferior_event status->kind = exited, status = 0 [Inferior 1 (process 10449) exited normally] infrun: stop_waiting infrun: stop_all_threads infrun: stop_all_threads, pass=0, iterations=0 infrun: process 10453 executing, need stop infrun: target_wait (-1.0.0, status) = infrun: 10453.10453.0 [process 10453], infrun: status->kind = exited, status = 0 infrun: stop_all_threads status->kind = exited, status = 0 process 10453 infrun: process 10453 executing, already stopping infrun: target_wait (-1.0.0, status) = infrun: -1.0.0 [process -1], infrun: status->kind = no-resumed infrun: infrun_async(0) infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping ... And this polling goes on forever. This patch prevents the infinite looping behavior. For the same scenario above, we obtain the following behavior: ... (gdb) continue Continuing. infrun: clear_proceed_status_thread (process 31229) infrun: clear_proceed_status_thread (process 31233) infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT) infrun: proceed: resuming process 31229 infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 31229] at 0x55555555514e infrun: infrun_async(1) infrun: prepare_to_wait infrun: proceed: resuming process 31233 infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 31233] at 0x55555555514e infrun: prepare_to_wait infrun: Found 2 inferiors, starting at #0 infrun: target_wait (-1.0.0, status) = infrun: 31229.31229.0 [process 31229], infrun: status->kind = exited, status = 0 infrun: handle_inferior_event status->kind = exited, status = 0 [Inferior 1 (process 31229) exited normally] infrun: stop_waiting infrun: stop_all_threads infrun: stop_all_threads, pass=0, iterations=0 infrun: process 31233 executing, need stop infrun: target_wait (-1.0.0, status) = infrun: 31233.31233.0 [process 31233], infrun: status->kind = exited, status = 0 infrun: stop_all_threads status->kind = exited, status = 0 process 31233 infrun: saving status status->kind = exited, status = 0 for 31233.31233.0 infrun: process 31233 not executing infrun: stop_all_threads, pass=1, iterations=1 infrun: process 31233 not executing infrun: stop_all_threads done (gdb) The exit event from Inferior 1 is received and shown to the user. The exit event from Inferior 2 is not displayed, but kept pending. (gdb) info inferiors Num Description Connection Executable * 1 <null> a.out 2 process 31233 1 (native) a.out (gdb) inferior 2 [Switching to inferior 2 [process 31233] (a.out)] [Switching to thread 2.1 (process 31233)] Couldn't get registers: No such process. (gdb) continue Continuing. infrun: clear_proceed_status_thread (process 31233) infrun: clear_proceed_status_thread: thread process 31233 has pending wait status status->kind = exited, status = 0 (currently_stepping=0). infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT) infrun: proceed: resuming process 31233 infrun: resume: thread process 31233 has pending wait status status->kind = exited, status = 0 (currently_stepping=0). infrun: prepare_to_wait infrun: Using pending wait status status->kind = exited, status = 0 for process 31233. infrun: target_wait (-1.0.0, status) = infrun: 31233.31233.0 [process 31233], infrun: status->kind = exited, status = 0 infrun: handle_inferior_event status->kind = exited, status = 0 [Inferior 2 (process 31233) exited normally] infrun: stop_waiting (gdb) info inferiors Num Description Connection Executable 1 <null> a.out * 2 <null> a.out (gdb) When a process exits and we leave the process exit event pending, we need to make sure that at least one thread is left listed in the inferior's thread list. This is necessary in order to make sure we have a thread that we can later resume, so the process exit event can be collected/reported. When native debugging, the GNU/Linux back end already makes sure that the last LWP isn't deleted. When remote debugging against GNU/Linux GDBserver, the GNU/Linux GDBserver backend also makes sure that the last thread isn't deleted until the process exit event is reported to GDBserver core. However, between the backend reporting the process exit event to GDBserver core, and GDB consuming the event, GDB may update the thread list and find no thread left in the process. The process exit event will be pending somewhere in GDBserver's stop reply queue, or gdb/remote.c's queue, or whathever other event queue inbetween GDBserver and infrun.c's handle_inferior_event. This patch tweaks remote.c's target_update_thread_list implementation to avoid deleting the last thread of an inferior. In the past, this case of inferior-with-no-threads led to a special case at the bottom of handle_no_resumed, where it reads: /* Note however that we may find no resumed thread because the whole process exited meanwhile (thus updating the thread list results in an empty thread list). In this case we know we'll be getting a process exit event shortly. */ for (inferior *inf : all_non_exited_inferiors (ecs->target)) In current master, that code path is still reachable with the gdb.threads/continue-pending-after-query.exp testcase, when tested against GDBserver, with "maint set target-non-stop" forced "on". With this patch, the scenario that loop was concerned about is still properly handled, because the loop above it finds the process's last thread with "executing" set to true, and thus the handle_no_resumed function still returns true. Since GNU/Linux native and remote are the only targets that support non-stop mode, and with this patch, we always make sure the inferior has at least one thread, this patch also removes that "inferior with no threads" special case handling from handle_no_resumed. Since remote.c now has a special case where we treat a thread that has already exited as if it was still alive, we might need to tweak remote.c's target_thread_alive implementation to return true for that thread without querying the remote side (which would say "no, not alive"). After inspecting all the target_thread_alive calls in the codebase, it seems that only the one from prune_threads could result in that thread being accidentally deleted. There's only one call to prune_threads in GDB's common code, so this patch handles this by replacing the prune_threads call with a delete_exited_threads call. This seems like an improvement anyway, because we'll still be doing what the comment suggests we want to do, and, we avoid remote protocol traffic. Regression-tested on X86_64 Linux. gdb/ChangeLog: 2020-05-14 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> Tom de Vries <tdevries@suse.de> Pedro Alves <palves@redhat.com> PR threads/25478 * infrun.c (stop_all_threads): Do NOT ignore TARGET_WAITKIND_NO_RESUMED, TARGET_WAITKIND_THREAD_EXITED, TARGET_WAITKIND_EXITED, TARGET_WAITKIND_SIGNALLED wait statuses received. (handle_no_resumed): Remove code handling a live inferior with no threads. * remote.c (has_single_non_exited_thread): New. (remote_target::update_thread_list): Do not delete a thread if is the last thread of the process. * thread.c (thread_select): Call delete_exited_threads instead of prune_threads. gdb/testsuite/ChangeLog: 2020-05-14 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> Pedro Alves <palves@redhat.com> * gdb.multi/multi-exit.c: New file. * gdb.multi/multi-exit.exp: New file. * gdb.multi/multi-kill.c: New file. * gdb.multi/multi-kill.exp: New file.
2020-05-14 13:59:54 +02:00
return -1
}
}
# We want to continue all processes.
gdb_test_no_output "set schedule-multiple on"
# Resume, but then kill all from outside.
gdb_test_multiple "continue" "continue processes" {
-re "Continuing.\[\r\n\]+" {
# Kill all processes at once.
set kill_cmd "kill -9"
for {set i 1} {$i <= $NUM_INFS} {incr i} {
append kill_cmd " $testpid($i)"
}
remote_exec target $kill_cmd
exp_continue
}
-re "Program terminated with signal.*$gdb_prompt $" {
pass $gdb_test_name
}
}
# Check that "continue" collects the process kill event, as many times
# as we have inferiors left.
for {set i 2} {$i <= $NUM_INFS} {incr i} {
with_test_prefix "inf $i" {
set live_inferior ""
# Pick any live inferior.
gdb_test_multiple "info inferiors" "" {
-re "($decimal) *process.*$gdb_prompt $" {
set live_inferior $expect_out(1,string)
}
}
if {$live_inferior == ""} {
return -1
}
gdb_test "inferior $live_inferior" \
".*Switching to inferior $live_inferior.*" \
"switch to inferior"
gdb_test "continue" \
"Program terminated with signal SIGKILL, .*" \
"continue to SIGKILL"
}
}
}