old-cross-binutils/gdb/testsuite/gdb.threads/forking-threads-plus-breakpoint.exp

168 lines
4.6 KiB
Text
Raw Normal View History

# Copyright (C) 2015-2016 Free Software Foundation, Inc.
gdbserver: Fix non-stop / fork / step-over issues Ref: https://sourceware.org/ml/gdb-patches/2015-07/msg00868.html This adds a test that has a multithreaded program have several threads continuously fork, while another thread continuously steps over a breakpoint. This exposes several intertwined issues, which this patch addresses: - When we're stopping and suspending threads, some thread may fork, and we missed setting its suspend count to 1, like we do when a new clone/thread is detected. When we next unsuspend threads, the fork child's suspend count goes below 0, which is bogus and fails an assertion. - If a step-over is cancelled because a signal arrives, but then gdb is not interested in the signal, we pass the signal straight back to the inferior. However, we miss that we need to re-increment the suspend counts of all other threads that had been paused for the step-over. As a result, other threads indefinitely end up stuck stopped. - If a detach request comes in just while gdbserver is handling a step-over (in the test at hand, this is GDB detaching the fork child), gdbserver internal errors in stabilize_thread's helpers, which assert that all thread's suspend counts are 0 (otherwise we wouldn't be able to move threads out of the jump pads). The suspend counts aren't 0 while a step-over is in progress, because all threads but the one stepping past the breakpoint must remain paused until the step-over finishes and the breakpoint can be reinserted. - Occasionally, we see "BAD - reinserting but not stepping." being output (from within linux_resume_one_lwp_throw). That was because GDB pokes memory while gdbserver is busy with a step-over, and that suspends threads, and then re-resumes them with proceed_one_lwp, which missed another reason to tell linux_resume_one_lwp that the thread should be set back to stepping. - In a couple places, we were resuming threads that are meant to be suspended. E.g., when a vCont;c/s request for thread B comes in just while gdbserver is stepping thread A past a breakpoint. The resume for thread B must be deferred until the step-over finishes. - The test runs with both "set detach-on-fork" on and off. When off, it exercises the case of GDB detaching the fork child explicitly. When on, it exercises the case of gdb resuming the child explicitly. In the "off" case, gdb seems to exponentially become slower as new inferiors are created. This is _very_ noticeable as with only 100 inferiors gdb is crawling already, which makes the test take quite a bit to run. For that reason, I've disabled the "off" variant for now. gdb/ChangeLog: 2015-08-06 Pedro Alves <palves@redhat.com> * target/waitstatus.h (enum target_stop_reason) <TARGET_STOPPED_BY_SINGLE_STEP>: New value. gdb/gdbserver/ChangeLog: 2015-08-06 Pedro Alves <palves@redhat.com> * linux-low.c (handle_extended_wait): Set the fork child's suspend count if stopping and suspending threads. (check_stopped_by_breakpoint): If stopped by trace, set the LWP's stop reason to TARGET_STOPPED_BY_SINGLE_STEP. (linux_detach): Complete an ongoing step-over. (lwp_suspended_inc, lwp_suspended_decr): New functions. Use throughout. (resume_stopped_resumed_lwps): Don't resume a suspended thread. (linux_wait_1): If passing a signal to the inferior after finishing a step-over, unsuspend and re-resume all lwps. If we see a single-step event but the thread should be continuing, don't pass the trap to gdb. (stuck_in_jump_pad_callback, move_out_of_jump_pad_callback): Use internal_error instead of gdb_assert. (enqueue_pending_signal): New function. (check_ptrace_stopped_lwp_gone): Add debug output. (start_step_over): Use internal_error instead of gdb_assert. (complete_ongoing_step_over): New function. (linux_resume_one_thread): Don't resume a suspended thread. (proceed_one_lwp): If the LWP is stepping over a breakpoint, reset it stepping. gdb/testsuite/ChangeLog: 2015-08-06 Pedro Alves <palves@redhat.com> * gdb.threads/forking-threads-plus-breakpoint.exp: New file. * gdb.threads/forking-threads-plus-breakpoint.c: New file.
2015-08-06 09:30:18 +00:00
# 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/>.
# This test verifies that several threads forking while another thread
# is constantly stepping over a breakpoint is properly handled.
standard_testfile
set linenum [gdb_get_line_number "set break here"]
if {[build_executable "failed to prepare" $testfile $srcfile {debug pthreads}] == -1} {
return -1
}
# Assume yes.
set displaced_stepping_supported 1
# "set displaced on" only tells gdb to use displaced stepping if
# possible. Probe for actual support.
proc probe_displaced_stepping_support {} {
global displaced_stepping_supported
global binfile gdb_prompt
with_test_prefix "probe displaced-stepping support" {
clean_restart $binfile
gdb_test_no_output "set displaced on"
if ![runto_main] then {
fail "Can't run to main"
return 0
}
# We're stopped at the main breakpoint. If displaced stepping is
# supported, we'll see related debug output while we step past
# that breakpoint.
gdb_test_no_output "set debug displaced 1"
gdb_test_multiple "next" "probe" {
-re "displaced pc to.*$gdb_prompt $" {
pass "supported"
}
-re ".*$gdb_prompt $" {
set displaced_stepping_supported 0
pass "not supported"
}
}
}
}
gdbserver: Fix non-stop / fork / step-over issues Ref: https://sourceware.org/ml/gdb-patches/2015-07/msg00868.html This adds a test that has a multithreaded program have several threads continuously fork, while another thread continuously steps over a breakpoint. This exposes several intertwined issues, which this patch addresses: - When we're stopping and suspending threads, some thread may fork, and we missed setting its suspend count to 1, like we do when a new clone/thread is detected. When we next unsuspend threads, the fork child's suspend count goes below 0, which is bogus and fails an assertion. - If a step-over is cancelled because a signal arrives, but then gdb is not interested in the signal, we pass the signal straight back to the inferior. However, we miss that we need to re-increment the suspend counts of all other threads that had been paused for the step-over. As a result, other threads indefinitely end up stuck stopped. - If a detach request comes in just while gdbserver is handling a step-over (in the test at hand, this is GDB detaching the fork child), gdbserver internal errors in stabilize_thread's helpers, which assert that all thread's suspend counts are 0 (otherwise we wouldn't be able to move threads out of the jump pads). The suspend counts aren't 0 while a step-over is in progress, because all threads but the one stepping past the breakpoint must remain paused until the step-over finishes and the breakpoint can be reinserted. - Occasionally, we see "BAD - reinserting but not stepping." being output (from within linux_resume_one_lwp_throw). That was because GDB pokes memory while gdbserver is busy with a step-over, and that suspends threads, and then re-resumes them with proceed_one_lwp, which missed another reason to tell linux_resume_one_lwp that the thread should be set back to stepping. - In a couple places, we were resuming threads that are meant to be suspended. E.g., when a vCont;c/s request for thread B comes in just while gdbserver is stepping thread A past a breakpoint. The resume for thread B must be deferred until the step-over finishes. - The test runs with both "set detach-on-fork" on and off. When off, it exercises the case of GDB detaching the fork child explicitly. When on, it exercises the case of gdb resuming the child explicitly. In the "off" case, gdb seems to exponentially become slower as new inferiors are created. This is _very_ noticeable as with only 100 inferiors gdb is crawling already, which makes the test take quite a bit to run. For that reason, I've disabled the "off" variant for now. gdb/ChangeLog: 2015-08-06 Pedro Alves <palves@redhat.com> * target/waitstatus.h (enum target_stop_reason) <TARGET_STOPPED_BY_SINGLE_STEP>: New value. gdb/gdbserver/ChangeLog: 2015-08-06 Pedro Alves <palves@redhat.com> * linux-low.c (handle_extended_wait): Set the fork child's suspend count if stopping and suspending threads. (check_stopped_by_breakpoint): If stopped by trace, set the LWP's stop reason to TARGET_STOPPED_BY_SINGLE_STEP. (linux_detach): Complete an ongoing step-over. (lwp_suspended_inc, lwp_suspended_decr): New functions. Use throughout. (resume_stopped_resumed_lwps): Don't resume a suspended thread. (linux_wait_1): If passing a signal to the inferior after finishing a step-over, unsuspend and re-resume all lwps. If we see a single-step event but the thread should be continuing, don't pass the trap to gdb. (stuck_in_jump_pad_callback, move_out_of_jump_pad_callback): Use internal_error instead of gdb_assert. (enqueue_pending_signal): New function. (check_ptrace_stopped_lwp_gone): Add debug output. (start_step_over): Use internal_error instead of gdb_assert. (complete_ongoing_step_over): New function. (linux_resume_one_thread): Don't resume a suspended thread. (proceed_one_lwp): If the LWP is stepping over a breakpoint, reset it stepping. gdb/testsuite/ChangeLog: 2015-08-06 Pedro Alves <palves@redhat.com> * gdb.threads/forking-threads-plus-breakpoint.exp: New file. * gdb.threads/forking-threads-plus-breakpoint.c: New file.
2015-08-06 09:30:18 +00:00
# The test proper. If COND_BP_TARGET is true, then test with
# conditional breakpoints evaluated on the target side, if possible.
# DETACH_ON_FORK is used as value for the "set detach-on-fork"
# setting. If "on", this exercises GDB explicitly continuing the fork
# child until exit. If "off", this exercises GDB detaching the fork
# child. DISPLACED indicates whether to use displaced stepping or
# not.
proc do_test { cond_bp_target detach_on_fork displaced } {
gdbserver: Fix non-stop / fork / step-over issues Ref: https://sourceware.org/ml/gdb-patches/2015-07/msg00868.html This adds a test that has a multithreaded program have several threads continuously fork, while another thread continuously steps over a breakpoint. This exposes several intertwined issues, which this patch addresses: - When we're stopping and suspending threads, some thread may fork, and we missed setting its suspend count to 1, like we do when a new clone/thread is detected. When we next unsuspend threads, the fork child's suspend count goes below 0, which is bogus and fails an assertion. - If a step-over is cancelled because a signal arrives, but then gdb is not interested in the signal, we pass the signal straight back to the inferior. However, we miss that we need to re-increment the suspend counts of all other threads that had been paused for the step-over. As a result, other threads indefinitely end up stuck stopped. - If a detach request comes in just while gdbserver is handling a step-over (in the test at hand, this is GDB detaching the fork child), gdbserver internal errors in stabilize_thread's helpers, which assert that all thread's suspend counts are 0 (otherwise we wouldn't be able to move threads out of the jump pads). The suspend counts aren't 0 while a step-over is in progress, because all threads but the one stepping past the breakpoint must remain paused until the step-over finishes and the breakpoint can be reinserted. - Occasionally, we see "BAD - reinserting but not stepping." being output (from within linux_resume_one_lwp_throw). That was because GDB pokes memory while gdbserver is busy with a step-over, and that suspends threads, and then re-resumes them with proceed_one_lwp, which missed another reason to tell linux_resume_one_lwp that the thread should be set back to stepping. - In a couple places, we were resuming threads that are meant to be suspended. E.g., when a vCont;c/s request for thread B comes in just while gdbserver is stepping thread A past a breakpoint. The resume for thread B must be deferred until the step-over finishes. - The test runs with both "set detach-on-fork" on and off. When off, it exercises the case of GDB detaching the fork child explicitly. When on, it exercises the case of gdb resuming the child explicitly. In the "off" case, gdb seems to exponentially become slower as new inferiors are created. This is _very_ noticeable as with only 100 inferiors gdb is crawling already, which makes the test take quite a bit to run. For that reason, I've disabled the "off" variant for now. gdb/ChangeLog: 2015-08-06 Pedro Alves <palves@redhat.com> * target/waitstatus.h (enum target_stop_reason) <TARGET_STOPPED_BY_SINGLE_STEP>: New value. gdb/gdbserver/ChangeLog: 2015-08-06 Pedro Alves <palves@redhat.com> * linux-low.c (handle_extended_wait): Set the fork child's suspend count if stopping and suspending threads. (check_stopped_by_breakpoint): If stopped by trace, set the LWP's stop reason to TARGET_STOPPED_BY_SINGLE_STEP. (linux_detach): Complete an ongoing step-over. (lwp_suspended_inc, lwp_suspended_decr): New functions. Use throughout. (resume_stopped_resumed_lwps): Don't resume a suspended thread. (linux_wait_1): If passing a signal to the inferior after finishing a step-over, unsuspend and re-resume all lwps. If we see a single-step event but the thread should be continuing, don't pass the trap to gdb. (stuck_in_jump_pad_callback, move_out_of_jump_pad_callback): Use internal_error instead of gdb_assert. (enqueue_pending_signal): New function. (check_ptrace_stopped_lwp_gone): Add debug output. (start_step_over): Use internal_error instead of gdb_assert. (complete_ongoing_step_over): New function. (linux_resume_one_thread): Don't resume a suspended thread. (proceed_one_lwp): If the LWP is stepping over a breakpoint, reset it stepping. gdb/testsuite/ChangeLog: 2015-08-06 Pedro Alves <palves@redhat.com> * gdb.threads/forking-threads-plus-breakpoint.exp: New file. * gdb.threads/forking-threads-plus-breakpoint.c: New file.
2015-08-06 09:30:18 +00:00
global GDBFLAGS
global srcfile testfile binfile
global decimal gdb_prompt
global linenum
global is_remote_target
set saved_gdbflags $GDBFLAGS
set GDBFLAGS [concat $GDBFLAGS " -ex \"set non-stop on\""]
clean_restart $binfile
set GDBFLAGS $saved_gdbflags
if ![runto_main] then {
fail "Can't run to main"
return 0
}
if {$cond_bp_target} {
set test "set breakpoint condition-evaluation target"
gdb_test_multiple $test $test {
-re "warning: Target does not support breakpoint condition evaluation.\r\nUsing host evaluation mode instead.\r\n$gdb_prompt $" {
# Target doesn't support breakpoint condition
# evaluation on its side. Skip the test.
return 0
}
-re "^$test\r\n$gdb_prompt $" {
}
}
} else {
gdb_test_no_output "set breakpoint condition-evaluation host"
}
gdbserver: Fix non-stop / fork / step-over issues Ref: https://sourceware.org/ml/gdb-patches/2015-07/msg00868.html This adds a test that has a multithreaded program have several threads continuously fork, while another thread continuously steps over a breakpoint. This exposes several intertwined issues, which this patch addresses: - When we're stopping and suspending threads, some thread may fork, and we missed setting its suspend count to 1, like we do when a new clone/thread is detected. When we next unsuspend threads, the fork child's suspend count goes below 0, which is bogus and fails an assertion. - If a step-over is cancelled because a signal arrives, but then gdb is not interested in the signal, we pass the signal straight back to the inferior. However, we miss that we need to re-increment the suspend counts of all other threads that had been paused for the step-over. As a result, other threads indefinitely end up stuck stopped. - If a detach request comes in just while gdbserver is handling a step-over (in the test at hand, this is GDB detaching the fork child), gdbserver internal errors in stabilize_thread's helpers, which assert that all thread's suspend counts are 0 (otherwise we wouldn't be able to move threads out of the jump pads). The suspend counts aren't 0 while a step-over is in progress, because all threads but the one stepping past the breakpoint must remain paused until the step-over finishes and the breakpoint can be reinserted. - Occasionally, we see "BAD - reinserting but not stepping." being output (from within linux_resume_one_lwp_throw). That was because GDB pokes memory while gdbserver is busy with a step-over, and that suspends threads, and then re-resumes them with proceed_one_lwp, which missed another reason to tell linux_resume_one_lwp that the thread should be set back to stepping. - In a couple places, we were resuming threads that are meant to be suspended. E.g., when a vCont;c/s request for thread B comes in just while gdbserver is stepping thread A past a breakpoint. The resume for thread B must be deferred until the step-over finishes. - The test runs with both "set detach-on-fork" on and off. When off, it exercises the case of GDB detaching the fork child explicitly. When on, it exercises the case of gdb resuming the child explicitly. In the "off" case, gdb seems to exponentially become slower as new inferiors are created. This is _very_ noticeable as with only 100 inferiors gdb is crawling already, which makes the test take quite a bit to run. For that reason, I've disabled the "off" variant for now. gdb/ChangeLog: 2015-08-06 Pedro Alves <palves@redhat.com> * target/waitstatus.h (enum target_stop_reason) <TARGET_STOPPED_BY_SINGLE_STEP>: New value. gdb/gdbserver/ChangeLog: 2015-08-06 Pedro Alves <palves@redhat.com> * linux-low.c (handle_extended_wait): Set the fork child's suspend count if stopping and suspending threads. (check_stopped_by_breakpoint): If stopped by trace, set the LWP's stop reason to TARGET_STOPPED_BY_SINGLE_STEP. (linux_detach): Complete an ongoing step-over. (lwp_suspended_inc, lwp_suspended_decr): New functions. Use throughout. (resume_stopped_resumed_lwps): Don't resume a suspended thread. (linux_wait_1): If passing a signal to the inferior after finishing a step-over, unsuspend and re-resume all lwps. If we see a single-step event but the thread should be continuing, don't pass the trap to gdb. (stuck_in_jump_pad_callback, move_out_of_jump_pad_callback): Use internal_error instead of gdb_assert. (enqueue_pending_signal): New function. (check_ptrace_stopped_lwp_gone): Add debug output. (start_step_over): Use internal_error instead of gdb_assert. (complete_ongoing_step_over): New function. (linux_resume_one_thread): Don't resume a suspended thread. (proceed_one_lwp): If the LWP is stepping over a breakpoint, reset it stepping. gdb/testsuite/ChangeLog: 2015-08-06 Pedro Alves <palves@redhat.com> * gdb.threads/forking-threads-plus-breakpoint.exp: New file. * gdb.threads/forking-threads-plus-breakpoint.c: New file.
2015-08-06 09:30:18 +00:00
gdb_test_no_output "set detach-on-fork $detach_on_fork"
gdb_test_no_output "set displaced $displaced"
gdbserver: Fix non-stop / fork / step-over issues Ref: https://sourceware.org/ml/gdb-patches/2015-07/msg00868.html This adds a test that has a multithreaded program have several threads continuously fork, while another thread continuously steps over a breakpoint. This exposes several intertwined issues, which this patch addresses: - When we're stopping and suspending threads, some thread may fork, and we missed setting its suspend count to 1, like we do when a new clone/thread is detected. When we next unsuspend threads, the fork child's suspend count goes below 0, which is bogus and fails an assertion. - If a step-over is cancelled because a signal arrives, but then gdb is not interested in the signal, we pass the signal straight back to the inferior. However, we miss that we need to re-increment the suspend counts of all other threads that had been paused for the step-over. As a result, other threads indefinitely end up stuck stopped. - If a detach request comes in just while gdbserver is handling a step-over (in the test at hand, this is GDB detaching the fork child), gdbserver internal errors in stabilize_thread's helpers, which assert that all thread's suspend counts are 0 (otherwise we wouldn't be able to move threads out of the jump pads). The suspend counts aren't 0 while a step-over is in progress, because all threads but the one stepping past the breakpoint must remain paused until the step-over finishes and the breakpoint can be reinserted. - Occasionally, we see "BAD - reinserting but not stepping." being output (from within linux_resume_one_lwp_throw). That was because GDB pokes memory while gdbserver is busy with a step-over, and that suspends threads, and then re-resumes them with proceed_one_lwp, which missed another reason to tell linux_resume_one_lwp that the thread should be set back to stepping. - In a couple places, we were resuming threads that are meant to be suspended. E.g., when a vCont;c/s request for thread B comes in just while gdbserver is stepping thread A past a breakpoint. The resume for thread B must be deferred until the step-over finishes. - The test runs with both "set detach-on-fork" on and off. When off, it exercises the case of GDB detaching the fork child explicitly. When on, it exercises the case of gdb resuming the child explicitly. In the "off" case, gdb seems to exponentially become slower as new inferiors are created. This is _very_ noticeable as with only 100 inferiors gdb is crawling already, which makes the test take quite a bit to run. For that reason, I've disabled the "off" variant for now. gdb/ChangeLog: 2015-08-06 Pedro Alves <palves@redhat.com> * target/waitstatus.h (enum target_stop_reason) <TARGET_STOPPED_BY_SINGLE_STEP>: New value. gdb/gdbserver/ChangeLog: 2015-08-06 Pedro Alves <palves@redhat.com> * linux-low.c (handle_extended_wait): Set the fork child's suspend count if stopping and suspending threads. (check_stopped_by_breakpoint): If stopped by trace, set the LWP's stop reason to TARGET_STOPPED_BY_SINGLE_STEP. (linux_detach): Complete an ongoing step-over. (lwp_suspended_inc, lwp_suspended_decr): New functions. Use throughout. (resume_stopped_resumed_lwps): Don't resume a suspended thread. (linux_wait_1): If passing a signal to the inferior after finishing a step-over, unsuspend and re-resume all lwps. If we see a single-step event but the thread should be continuing, don't pass the trap to gdb. (stuck_in_jump_pad_callback, move_out_of_jump_pad_callback): Use internal_error instead of gdb_assert. (enqueue_pending_signal): New function. (check_ptrace_stopped_lwp_gone): Add debug output. (start_step_over): Use internal_error instead of gdb_assert. (complete_ongoing_step_over): New function. (linux_resume_one_thread): Don't resume a suspended thread. (proceed_one_lwp): If the LWP is stepping over a breakpoint, reset it stepping. gdb/testsuite/ChangeLog: 2015-08-06 Pedro Alves <palves@redhat.com> * gdb.threads/forking-threads-plus-breakpoint.exp: New file. * gdb.threads/forking-threads-plus-breakpoint.c: New file.
2015-08-06 09:30:18 +00:00
gdb_test "break $linenum if zero == 1" \
"Breakpoint .*" \
"set breakpoint that evals false"
set test "continue &"
gdb_test_multiple $test $test {
-re "$gdb_prompt " {
pass $test
}
}
set fork_count 0
set ok 0
set test "inferior 1 exited"
gdb_test_multiple "" $test {
-re "Inferior 1 \(\[^\r\n\]+\) exited normally" {
set ok 1
pass $test
}
-re "Inferior $decimal \(\[^\r\n\]+\) exited normally" {
incr fork_count
if {$fork_count <= 100} {
exp_continue
} else {
fail "$test (too many forks)"
}
}
}
if {!$ok} {
# No use testing further.
return
}
gdb_test "info threads" "No threads\." \
"no threads left"
gdb_test "info inferiors" \
"Num\[ \t\]+Description\[ \t\]+Executable\[ \t\]+\r\n\\* 1 \[^\r\n\]+" \
"only inferior 1 left"
}
probe_displaced_stepping_support
gdbserver: Fix non-stop / fork / step-over issues Ref: https://sourceware.org/ml/gdb-patches/2015-07/msg00868.html This adds a test that has a multithreaded program have several threads continuously fork, while another thread continuously steps over a breakpoint. This exposes several intertwined issues, which this patch addresses: - When we're stopping and suspending threads, some thread may fork, and we missed setting its suspend count to 1, like we do when a new clone/thread is detected. When we next unsuspend threads, the fork child's suspend count goes below 0, which is bogus and fails an assertion. - If a step-over is cancelled because a signal arrives, but then gdb is not interested in the signal, we pass the signal straight back to the inferior. However, we miss that we need to re-increment the suspend counts of all other threads that had been paused for the step-over. As a result, other threads indefinitely end up stuck stopped. - If a detach request comes in just while gdbserver is handling a step-over (in the test at hand, this is GDB detaching the fork child), gdbserver internal errors in stabilize_thread's helpers, which assert that all thread's suspend counts are 0 (otherwise we wouldn't be able to move threads out of the jump pads). The suspend counts aren't 0 while a step-over is in progress, because all threads but the one stepping past the breakpoint must remain paused until the step-over finishes and the breakpoint can be reinserted. - Occasionally, we see "BAD - reinserting but not stepping." being output (from within linux_resume_one_lwp_throw). That was because GDB pokes memory while gdbserver is busy with a step-over, and that suspends threads, and then re-resumes them with proceed_one_lwp, which missed another reason to tell linux_resume_one_lwp that the thread should be set back to stepping. - In a couple places, we were resuming threads that are meant to be suspended. E.g., when a vCont;c/s request for thread B comes in just while gdbserver is stepping thread A past a breakpoint. The resume for thread B must be deferred until the step-over finishes. - The test runs with both "set detach-on-fork" on and off. When off, it exercises the case of GDB detaching the fork child explicitly. When on, it exercises the case of gdb resuming the child explicitly. In the "off" case, gdb seems to exponentially become slower as new inferiors are created. This is _very_ noticeable as with only 100 inferiors gdb is crawling already, which makes the test take quite a bit to run. For that reason, I've disabled the "off" variant for now. gdb/ChangeLog: 2015-08-06 Pedro Alves <palves@redhat.com> * target/waitstatus.h (enum target_stop_reason) <TARGET_STOPPED_BY_SINGLE_STEP>: New value. gdb/gdbserver/ChangeLog: 2015-08-06 Pedro Alves <palves@redhat.com> * linux-low.c (handle_extended_wait): Set the fork child's suspend count if stopping and suspending threads. (check_stopped_by_breakpoint): If stopped by trace, set the LWP's stop reason to TARGET_STOPPED_BY_SINGLE_STEP. (linux_detach): Complete an ongoing step-over. (lwp_suspended_inc, lwp_suspended_decr): New functions. Use throughout. (resume_stopped_resumed_lwps): Don't resume a suspended thread. (linux_wait_1): If passing a signal to the inferior after finishing a step-over, unsuspend and re-resume all lwps. If we see a single-step event but the thread should be continuing, don't pass the trap to gdb. (stuck_in_jump_pad_callback, move_out_of_jump_pad_callback): Use internal_error instead of gdb_assert. (enqueue_pending_signal): New function. (check_ptrace_stopped_lwp_gone): Add debug output. (start_step_over): Use internal_error instead of gdb_assert. (complete_ongoing_step_over): New function. (linux_resume_one_thread): Don't resume a suspended thread. (proceed_one_lwp): If the LWP is stepping over a breakpoint, reset it stepping. gdb/testsuite/ChangeLog: 2015-08-06 Pedro Alves <palves@redhat.com> * gdb.threads/forking-threads-plus-breakpoint.exp: New file. * gdb.threads/forking-threads-plus-breakpoint.c: New file.
2015-08-06 09:30:18 +00:00
foreach_with_prefix cond_bp_target {1 0} {
foreach_with_prefix detach_on_fork {"on" "off"} {
gdbserver: Fix non-stop / fork / step-over issues Ref: https://sourceware.org/ml/gdb-patches/2015-07/msg00868.html This adds a test that has a multithreaded program have several threads continuously fork, while another thread continuously steps over a breakpoint. This exposes several intertwined issues, which this patch addresses: - When we're stopping and suspending threads, some thread may fork, and we missed setting its suspend count to 1, like we do when a new clone/thread is detected. When we next unsuspend threads, the fork child's suspend count goes below 0, which is bogus and fails an assertion. - If a step-over is cancelled because a signal arrives, but then gdb is not interested in the signal, we pass the signal straight back to the inferior. However, we miss that we need to re-increment the suspend counts of all other threads that had been paused for the step-over. As a result, other threads indefinitely end up stuck stopped. - If a detach request comes in just while gdbserver is handling a step-over (in the test at hand, this is GDB detaching the fork child), gdbserver internal errors in stabilize_thread's helpers, which assert that all thread's suspend counts are 0 (otherwise we wouldn't be able to move threads out of the jump pads). The suspend counts aren't 0 while a step-over is in progress, because all threads but the one stepping past the breakpoint must remain paused until the step-over finishes and the breakpoint can be reinserted. - Occasionally, we see "BAD - reinserting but not stepping." being output (from within linux_resume_one_lwp_throw). That was because GDB pokes memory while gdbserver is busy with a step-over, and that suspends threads, and then re-resumes them with proceed_one_lwp, which missed another reason to tell linux_resume_one_lwp that the thread should be set back to stepping. - In a couple places, we were resuming threads that are meant to be suspended. E.g., when a vCont;c/s request for thread B comes in just while gdbserver is stepping thread A past a breakpoint. The resume for thread B must be deferred until the step-over finishes. - The test runs with both "set detach-on-fork" on and off. When off, it exercises the case of GDB detaching the fork child explicitly. When on, it exercises the case of gdb resuming the child explicitly. In the "off" case, gdb seems to exponentially become slower as new inferiors are created. This is _very_ noticeable as with only 100 inferiors gdb is crawling already, which makes the test take quite a bit to run. For that reason, I've disabled the "off" variant for now. gdb/ChangeLog: 2015-08-06 Pedro Alves <palves@redhat.com> * target/waitstatus.h (enum target_stop_reason) <TARGET_STOPPED_BY_SINGLE_STEP>: New value. gdb/gdbserver/ChangeLog: 2015-08-06 Pedro Alves <palves@redhat.com> * linux-low.c (handle_extended_wait): Set the fork child's suspend count if stopping and suspending threads. (check_stopped_by_breakpoint): If stopped by trace, set the LWP's stop reason to TARGET_STOPPED_BY_SINGLE_STEP. (linux_detach): Complete an ongoing step-over. (lwp_suspended_inc, lwp_suspended_decr): New functions. Use throughout. (resume_stopped_resumed_lwps): Don't resume a suspended thread. (linux_wait_1): If passing a signal to the inferior after finishing a step-over, unsuspend and re-resume all lwps. If we see a single-step event but the thread should be continuing, don't pass the trap to gdb. (stuck_in_jump_pad_callback, move_out_of_jump_pad_callback): Use internal_error instead of gdb_assert. (enqueue_pending_signal): New function. (check_ptrace_stopped_lwp_gone): Add debug output. (start_step_over): Use internal_error instead of gdb_assert. (complete_ongoing_step_over): New function. (linux_resume_one_thread): Don't resume a suspended thread. (proceed_one_lwp): If the LWP is stepping over a breakpoint, reset it stepping. gdb/testsuite/ChangeLog: 2015-08-06 Pedro Alves <palves@redhat.com> * gdb.threads/forking-threads-plus-breakpoint.exp: New file. * gdb.threads/forking-threads-plus-breakpoint.c: New file.
2015-08-06 09:30:18 +00:00
# Disable "off" for now. The test does pass with
# detach-on-fork off (at the time of writing), but gdb seems
# to slow down quadratically as inferiors are created, and
# then the test takes annoyingly long to complete...
if {$detach_on_fork == "off"} {
continue
}
foreach_with_prefix displaced {"on" "off"} {
if {$displaced == "on" && !$displaced_stepping_supported} {
continue
}
do_test $cond_bp_target $detach_on_fork $displaced
}
gdbserver: Fix non-stop / fork / step-over issues Ref: https://sourceware.org/ml/gdb-patches/2015-07/msg00868.html This adds a test that has a multithreaded program have several threads continuously fork, while another thread continuously steps over a breakpoint. This exposes several intertwined issues, which this patch addresses: - When we're stopping and suspending threads, some thread may fork, and we missed setting its suspend count to 1, like we do when a new clone/thread is detected. When we next unsuspend threads, the fork child's suspend count goes below 0, which is bogus and fails an assertion. - If a step-over is cancelled because a signal arrives, but then gdb is not interested in the signal, we pass the signal straight back to the inferior. However, we miss that we need to re-increment the suspend counts of all other threads that had been paused for the step-over. As a result, other threads indefinitely end up stuck stopped. - If a detach request comes in just while gdbserver is handling a step-over (in the test at hand, this is GDB detaching the fork child), gdbserver internal errors in stabilize_thread's helpers, which assert that all thread's suspend counts are 0 (otherwise we wouldn't be able to move threads out of the jump pads). The suspend counts aren't 0 while a step-over is in progress, because all threads but the one stepping past the breakpoint must remain paused until the step-over finishes and the breakpoint can be reinserted. - Occasionally, we see "BAD - reinserting but not stepping." being output (from within linux_resume_one_lwp_throw). That was because GDB pokes memory while gdbserver is busy with a step-over, and that suspends threads, and then re-resumes them with proceed_one_lwp, which missed another reason to tell linux_resume_one_lwp that the thread should be set back to stepping. - In a couple places, we were resuming threads that are meant to be suspended. E.g., when a vCont;c/s request for thread B comes in just while gdbserver is stepping thread A past a breakpoint. The resume for thread B must be deferred until the step-over finishes. - The test runs with both "set detach-on-fork" on and off. When off, it exercises the case of GDB detaching the fork child explicitly. When on, it exercises the case of gdb resuming the child explicitly. In the "off" case, gdb seems to exponentially become slower as new inferiors are created. This is _very_ noticeable as with only 100 inferiors gdb is crawling already, which makes the test take quite a bit to run. For that reason, I've disabled the "off" variant for now. gdb/ChangeLog: 2015-08-06 Pedro Alves <palves@redhat.com> * target/waitstatus.h (enum target_stop_reason) <TARGET_STOPPED_BY_SINGLE_STEP>: New value. gdb/gdbserver/ChangeLog: 2015-08-06 Pedro Alves <palves@redhat.com> * linux-low.c (handle_extended_wait): Set the fork child's suspend count if stopping and suspending threads. (check_stopped_by_breakpoint): If stopped by trace, set the LWP's stop reason to TARGET_STOPPED_BY_SINGLE_STEP. (linux_detach): Complete an ongoing step-over. (lwp_suspended_inc, lwp_suspended_decr): New functions. Use throughout. (resume_stopped_resumed_lwps): Don't resume a suspended thread. (linux_wait_1): If passing a signal to the inferior after finishing a step-over, unsuspend and re-resume all lwps. If we see a single-step event but the thread should be continuing, don't pass the trap to gdb. (stuck_in_jump_pad_callback, move_out_of_jump_pad_callback): Use internal_error instead of gdb_assert. (enqueue_pending_signal): New function. (check_ptrace_stopped_lwp_gone): Add debug output. (start_step_over): Use internal_error instead of gdb_assert. (complete_ongoing_step_over): New function. (linux_resume_one_thread): Don't resume a suspended thread. (proceed_one_lwp): If the LWP is stepping over a breakpoint, reset it stepping. gdb/testsuite/ChangeLog: 2015-08-06 Pedro Alves <palves@redhat.com> * gdb.threads/forking-threads-plus-breakpoint.exp: New file. * gdb.threads/forking-threads-plus-breakpoint.c: New file.
2015-08-06 09:30:18 +00:00
}
}