binutils-gdb/gdb/testsuite/gdb.threads/vfork-multi-inferior.exp
Simon Marchi 5a0c4a06eb gdb/linux-nat: remove check based on current_inferior in linux_handle_extended_wait
The check removed by this patch, using current_inferior, looks wrong.
When debugging multiple inferiors with the Linux native target and
linux_handle_extended_wait is called, there's no guarantee about which
is the current inferior.  The vfork-done event we receive could be for
any inferior.  If the vfork-done event is for a non-current inferior, we
end up wrongfully ignoring it.  As a result, the core never processes a
TARGET_WAITKIND_VFORK_DONE event, program_space::breakpoints_not_allowed
is never cleared, and breakpoints are never reinserted.  However,
because the Linux native target decided to ignore the event, it resumed
the thread - while breakpoints out.  And that's bad.

The proposed fix is to remove this check.  Always report vfork-done
events and let infrun's logic decide if it should be ignored.  We don't
save much cycles by filtering the event here.

Add a test that replicates the situation described above.  See comments
in the test for more details.

Change-Id: Ibe33c1716c3602e847be6c2093120696f2286fbf
2022-03-31 13:07:21 -04:00

116 lines
4.3 KiB
Plaintext

# Copyright 2020-2022 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 handling a vfork while another inferior is running. The bug that
# prompted writing this test case was in the Linux native target. The target
# assumed that the vfork-done event it received was for the current inferior
# (an invalid assumption, the current inferior is the one randomly selected by
# do_target_wait (at the time of writing). This caused the target to drop the
# vfork-done event, because it was seen as unneeded and to restart the thread
# as if nothing happened. This however resulted in the thread running with
# breakpoints not inserted.
#
# To catch the bug, this test verifies that we can hit a breakpoint after a
# vfork call, while a second inferior runs in the background.
if [use_gdb_stub] {
unsupported "test uses multiple inferiors"
return
}
standard_testfile .c -sleep.c
set srcfile_sleep $srcfile2
set binfile_sleep ${binfile}-sleep
# The reproducibility of the bug depends on which inferior randomly selects in
# do_target_wait when consuming the vfork-done event. Since GDB doesn't call
# srand(), we are likely to always see the same sequence of inferior selected by
# do_target_wait, which can hide the bug if you are not "lucky". To work
# around that, call vfork and hit the breakpoint in a loop, it makes it
# somewhat likely that the wrong inferior will be selected eventually.
set nr_loops 20
# Compile the main program that calls vfork and hits a breakpoint.
set opts [list debug additional_flags=-DNR_LOOPS=$nr_loops]
if { [gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable \
$opts] != "" } {
untested "failed to compile"
return -1
}
# Compile the secondary program, which just sleeps.
if { [gdb_compile "${srcdir}/${subdir}/${srcfile_sleep}" "${binfile_sleep}" executable \
{debug}] != "" } {
untested "failed to compile"
return -1
}
# We exercise two methods of getting a second inferior to execute while the
# first one vforks. METHOD can be:
#
# - non-stop: start GDB with non-stop on and run the second inferior in
# background.
# - schedule-multiple: set "schedule-multiple on", this will make "continue"
# resume both inferiors.
proc do_test {method} {
save_vars { ::GDBFLAGS } {
if { $method == "non-stop" } {
append ::GDBFLAGS " -ex \"set non-stop on\""
}
clean_restart
}
# Start the second inferior in background.
gdb_test "add-inferior" "Added inferior 2.*"
gdb_test "inferior 2" "Switching to inferior 2 .*"
gdb_file_cmd ${::binfile_sleep}
if { $method == "non-stop" } {
gdb_test "run &" "Starting program: .*" "run inferior 2"
} else {
gdb_test "start" "Temporary breakpoint $::decimal, main .*" \
"start inferior 2"
}
# Start the first inferior.
gdb_test "inferior 1" "Switching to inferior 1 .*"
gdb_file_cmd ${::binfile}
gdb_test "break should_break_here" "Breakpoint $::decimal at .*"
gdb_test "start" "Thread 1.1 .* hit Temporary breakpoint.*" \
"start inferior 1"
# Only enable schedule-multiple this late, because of:
# https://sourceware.org/bugzilla/show_bug.cgi?id=28777
if { $method == "schedule-multiple" } {
gdb_test_no_output "set schedule-multiple on"
}
# Continue over vfork and until the breakpoint. The number of loops here
# matches the number of loops in the program. So if a breakpoint is missed
# at some point, a "continue" will wrongfully continue until the end of the
# program, which will fail the test.
for {set i 0} {$i < $::nr_loops} {incr i} {
with_test_prefix "i=$i" {
gdb_test "continue" \
"Thread 1.1 .* hit Breakpoint $::decimal, should_break_here.*"
}
}
}
foreach_with_prefix method {schedule-multiple non-stop} {
do_test $method
}