binutils-gdb/gdb/testsuite/gdb.threads/schedlock.exp

322 lines
8.1 KiB
Plaintext
Raw Normal View History

# Copyright (C) 1996-2019 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/>.
# This file was written by Daniel Jacobowitz <drow@mvista.com>
# (parts based on pthreads.exp by Fred Fish (fnf@cygnus.com).
#
# This test covers the various forms of "set scheduler-locking".
# This test requires sending ^C to interrupt the running target.
if [target_info exists gdb,nointerrupts] {
verbose "Skipping schedlock.exp because of nointerrupts."
return
}
* gdb.threads/watchpoint-fork.exp (test): Use standard_output_file. Don't declare objdir. * gdb.threads/attach-into-signal.exp: Use standard_testfile, standard_output_file. * gdb.threads/attach-stopped.exp: Use standard_testfile. * gdb.threads/bp_in_thread.exp: Use standard_testfile, clean_restart. Remove incdir. * gdb.threads/corethreads.exp: Use standard_testfile. * gdb.threads/execl.exp: Use standard_testfile, standard_output_file, clean_restart. * gdb.threads/fork-child-threads.exp: Use standard_testfile, clean_restart. * gdb.threads/fork-thread-pending.exp: Use standard_testfile, clean_restart. * gdb.threads/gcore-thread.exp: Use standard_testfile. Remove incdir. * gdb.threads/hand-call-in-threads.exp: Use standard_testfile, clean_restart. Remove incdir. * gdb.threads/ia64-sigill.exp: Use standard_testfile. * gdb.threads/interrupted-hand-call.exp: Use standard_testfile, clean_restart. Remove incdir. * gdb.threads/killed.exp: Use standard_testfile, clean_restart. Remove incdir. * gdb.threads/leader-exit.exp: Use standard_testfile. * gdb.threads/linux-dp.exp: Use standard_testfile, clean_restart. * gdb.threads/local-watch-wrong-thread.exp: Use standard_testfile, clean_restart. * gdb.threads/manythreads.exp: Use standard_testfile, clean_restart. Remove incdir. * gdb.threads/multi-create.exp: Use standard_testfile, clean_restart. * gdb.threads/no-unwaited-for-left.exp: Use standard_testfile. * gdb.threads/non-ldr-exc-1.exp: Use standard_testfile. * gdb.threads/non-ldr-exc-2.exp: Use standard_testfile. * gdb.threads/non-ldr-exc-3.exp: Use standard_testfile. * gdb.threads/non-ldr-exc-4.exp: Use standard_testfile. * gdb.threads/pending-step.exp: Use standard_testfile, clean_restart. Remove incdir. * gdb.threads/print-threads.exp: Use standard_testfile, clean_restart. Remove incdir. * gdb.threads/pthread_cond_wait.exp: Use standard_testfile, clean_restart. Remove incdir. * gdb.threads/pthreads.exp: Use standard_testfile, clean_restart. Remove incdir. * gdb.threads/schedlock.exp: Use standard_testfile. Remove incdir. * gdb.threads/sigthread.exp: Use standard_testfile, clean_restart. * gdb.threads/staticthreads.exp: Use standard_testfile, clean_restart. Remove incdir. * gdb.threads/switch-threads.exp: Use standard_testfile, clean_restart. Remove incdir. * gdb.threads/thread-execl.exp: Use standard_testfile, clean_restart. Remove incdir. * gdb.threads/thread-find.exp: Use standard_testfile, clean_restart. * gdb.threads/thread-specific.exp: Use standard_testfile, clean_restart. Remove incdir. * gdb.threads/thread-unwindonsignal.exp: Use standard_testfile, clean_restart. Remove incdir. * gdb.threads/thread_check.exp: Use standard_testfile, clean_restart. Remove incdir. * gdb.threads/thread_events.exp: Use standard_testfile. Remove incdir. * gdb.threads/threadapply.exp: Use standard_testfile, clean_restart. Remove incdir. * gdb.threads/threxit-hop-specific.exp: Use standard_testfile, clean_restart. Remove incdir. * gdb.threads/tls-nodebug.exp: Use standard_testfile, clean_restart. * gdb.threads/tls-shared.exp: Use standard_testfile, clean_restart, standard_output_file. * gdb.threads/tls-var.exp: Use standard_testfile, standard_output_file. * gdb.threads/tls.exp: Use standard_testfile, clean_restart. Remove incdir. * gdb.threads/watchthreads-reorder.exp: Use standard_testfile. * gdb.threads/watchthreads.exp: Use standard_testfile. Remove incdir. * gdb.threads/watchthreads2.exp: Use standard_testfile, clean_restart. Remove incdir.
2012-06-26 21:23:20 +02:00
standard_testfile
# The number of threads, including the main thread.
set NUM 2
* gdb.threads/watchpoint-fork.exp (test): Use standard_output_file. Don't declare objdir. * gdb.threads/attach-into-signal.exp: Use standard_testfile, standard_output_file. * gdb.threads/attach-stopped.exp: Use standard_testfile. * gdb.threads/bp_in_thread.exp: Use standard_testfile, clean_restart. Remove incdir. * gdb.threads/corethreads.exp: Use standard_testfile. * gdb.threads/execl.exp: Use standard_testfile, standard_output_file, clean_restart. * gdb.threads/fork-child-threads.exp: Use standard_testfile, clean_restart. * gdb.threads/fork-thread-pending.exp: Use standard_testfile, clean_restart. * gdb.threads/gcore-thread.exp: Use standard_testfile. Remove incdir. * gdb.threads/hand-call-in-threads.exp: Use standard_testfile, clean_restart. Remove incdir. * gdb.threads/ia64-sigill.exp: Use standard_testfile. * gdb.threads/interrupted-hand-call.exp: Use standard_testfile, clean_restart. Remove incdir. * gdb.threads/killed.exp: Use standard_testfile, clean_restart. Remove incdir. * gdb.threads/leader-exit.exp: Use standard_testfile. * gdb.threads/linux-dp.exp: Use standard_testfile, clean_restart. * gdb.threads/local-watch-wrong-thread.exp: Use standard_testfile, clean_restart. * gdb.threads/manythreads.exp: Use standard_testfile, clean_restart. Remove incdir. * gdb.threads/multi-create.exp: Use standard_testfile, clean_restart. * gdb.threads/no-unwaited-for-left.exp: Use standard_testfile. * gdb.threads/non-ldr-exc-1.exp: Use standard_testfile. * gdb.threads/non-ldr-exc-2.exp: Use standard_testfile. * gdb.threads/non-ldr-exc-3.exp: Use standard_testfile. * gdb.threads/non-ldr-exc-4.exp: Use standard_testfile. * gdb.threads/pending-step.exp: Use standard_testfile, clean_restart. Remove incdir. * gdb.threads/print-threads.exp: Use standard_testfile, clean_restart. Remove incdir. * gdb.threads/pthread_cond_wait.exp: Use standard_testfile, clean_restart. Remove incdir. * gdb.threads/pthreads.exp: Use standard_testfile, clean_restart. Remove incdir. * gdb.threads/schedlock.exp: Use standard_testfile. Remove incdir. * gdb.threads/sigthread.exp: Use standard_testfile, clean_restart. * gdb.threads/staticthreads.exp: Use standard_testfile, clean_restart. Remove incdir. * gdb.threads/switch-threads.exp: Use standard_testfile, clean_restart. Remove incdir. * gdb.threads/thread-execl.exp: Use standard_testfile, clean_restart. Remove incdir. * gdb.threads/thread-find.exp: Use standard_testfile, clean_restart. * gdb.threads/thread-specific.exp: Use standard_testfile, clean_restart. Remove incdir. * gdb.threads/thread-unwindonsignal.exp: Use standard_testfile, clean_restart. Remove incdir. * gdb.threads/thread_check.exp: Use standard_testfile, clean_restart. Remove incdir. * gdb.threads/thread_events.exp: Use standard_testfile. Remove incdir. * gdb.threads/threadapply.exp: Use standard_testfile, clean_restart. Remove incdir. * gdb.threads/threxit-hop-specific.exp: Use standard_testfile, clean_restart. Remove incdir. * gdb.threads/tls-nodebug.exp: Use standard_testfile, clean_restart. * gdb.threads/tls-shared.exp: Use standard_testfile, clean_restart, standard_output_file. * gdb.threads/tls-var.exp: Use standard_testfile, standard_output_file. * gdb.threads/tls.exp: Use standard_testfile, clean_restart. Remove incdir. * gdb.threads/watchthreads-reorder.exp: Use standard_testfile. * gdb.threads/watchthreads.exp: Use standard_testfile. Remove incdir. * gdb.threads/watchthreads2.exp: Use standard_testfile, clean_restart. Remove incdir.
2012-06-26 21:23:20 +02:00
if {[gdb_compile_pthreads "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable debug] != "" } {
return -1
}
# Now we can proceed with the real testing.
PR 17408 - assertion failure in switch_back_to_stepped_thread This PR shows that GDB can easily trigger an assertion here, in infrun.c: 5392 /* Did we find the stepping thread? */ 5393 if (tp->control.step_range_end) 5394 { 5395 /* Yep. There should only one though. */ 5396 gdb_assert (stepping_thread == NULL); 5397 5398 /* The event thread is handled at the top, before we 5399 enter this loop. */ 5400 gdb_assert (tp != ecs->event_thread); 5401 5402 /* If some thread other than the event thread is 5403 stepping, then scheduler locking can't be in effect, 5404 otherwise we wouldn't have resumed the current event 5405 thread in the first place. */ 5406 gdb_assert (!schedlock_applies (currently_stepping (tp))); 5407 5408 stepping_thread = tp; 5409 } Like: gdb/infrun.c:5406: internal-error: switch_back_to_stepped_thread: Assertion `!schedlock_applies (1)' failed. The way the assertion is written is assuming that with schedlock=step we'll always leave threads other than the one with the stepping range locked, while that's not true with the "next" command. With schedlock "step", other threads still run unlocked when "next" detects a function call and steps over it. Whether that makes sense or not, still, it's documented that way in the manual. If another thread hits an event that doesn't cause a stop while the nexting thread steps over a function call, we'll get here and fail the assertion. The fix is just to adjust the assertion. Even though we found the stepping thread, we'll still step-over the breakpoint that just triggered correctly. Surprisingly, gdb.threads/schedlock.exp doesn't have any test that steps over a function call. This commits fixes that. This ensures that "next" doesn't switch focus to another thread, and checks whether other threads run locked or not, depending on scheduler locking mode and command. There's a lot of duplication in that file that this ends cleaning up. There's more that could be cleaned up, but that would end up an unrelated change, best done separately. This new coverage in schedlock.exp happens to trigger the internal error in question, like so: FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (1) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (3) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (5) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (7) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (9) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next does not change thread (switched to thread 0) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: current thread advanced - unlocked (wrong amount) That's because we have more than one thread running the same loop, and while one thread is stepping over a function call, the other thread hits the step-resume breakpoint of the first, which needs to be stepped over, and we end up in switch_back_to_stepped_thread exactly in the problem case. I think a simpler and more directed test is also useful, to not rely on internal breakpoint magics. So this commit also adds a test that has a thread trip on a conditional breakpoint that doesn't cause a user-visible stop while another thread is stepping over a call. That currently fails like this: FAIL: gdb.threads/next-bp-other-thread.exp: schedlock=step: next over function call (GDB internal error) Tested on x86_64 Fedora 20. gdb/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * infrun.c (switch_back_to_stepped_thread): Use currently_stepping instead of assuming a thread with a stepping range is always stepping. gdb/testsuite/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * gdb.threads/schedlock.c (some_function): New function. (call_function): New global. (MAYBE_CALL_SOME_FUNCTION): New macro. (thread_function): Call it. * gdb.threads/schedlock.exp (get_args): Add description parameter, and use it instead of a global counter. Adjust all callers. (get_current_thread): Use "find current thread" for test message here rather than having all callers pass down the same string. (goto_loop): New procedure, factored out from ... (my_continue): ... this. (step_ten_loops): Change parameter from test message to command to use. Adjust. (list_count): Delete global. (check_result): New procedure, factored out from duplicate top level code. (continue tests): Wrap in with_test_prefix. (test_step): New procedure, factored out from duplicate top level code. (top level): Test "step" in combination with all scheduler-locking modes. Test "next" in combination with all scheduler-locking modes, and in combination with stepping over a function call or not. * gdb.threads/next-bp-other-thread.c: New file. * gdb.threads/next-bp-other-thread.exp: New file.
2014-10-29 19:15:39 +01:00
# Get the current contents of the `args` array in the test program.
# Description is appended to the test message.
proc get_args { description } {
global gdb_prompt
global NUM
set pattern "(\[0-9\]+)"
for {set i 1} {[expr $i < $NUM]} {incr i} {
append pattern ", (\[0-9\]+)"
}
PR 17408 - assertion failure in switch_back_to_stepped_thread This PR shows that GDB can easily trigger an assertion here, in infrun.c: 5392 /* Did we find the stepping thread? */ 5393 if (tp->control.step_range_end) 5394 { 5395 /* Yep. There should only one though. */ 5396 gdb_assert (stepping_thread == NULL); 5397 5398 /* The event thread is handled at the top, before we 5399 enter this loop. */ 5400 gdb_assert (tp != ecs->event_thread); 5401 5402 /* If some thread other than the event thread is 5403 stepping, then scheduler locking can't be in effect, 5404 otherwise we wouldn't have resumed the current event 5405 thread in the first place. */ 5406 gdb_assert (!schedlock_applies (currently_stepping (tp))); 5407 5408 stepping_thread = tp; 5409 } Like: gdb/infrun.c:5406: internal-error: switch_back_to_stepped_thread: Assertion `!schedlock_applies (1)' failed. The way the assertion is written is assuming that with schedlock=step we'll always leave threads other than the one with the stepping range locked, while that's not true with the "next" command. With schedlock "step", other threads still run unlocked when "next" detects a function call and steps over it. Whether that makes sense or not, still, it's documented that way in the manual. If another thread hits an event that doesn't cause a stop while the nexting thread steps over a function call, we'll get here and fail the assertion. The fix is just to adjust the assertion. Even though we found the stepping thread, we'll still step-over the breakpoint that just triggered correctly. Surprisingly, gdb.threads/schedlock.exp doesn't have any test that steps over a function call. This commits fixes that. This ensures that "next" doesn't switch focus to another thread, and checks whether other threads run locked or not, depending on scheduler locking mode and command. There's a lot of duplication in that file that this ends cleaning up. There's more that could be cleaned up, but that would end up an unrelated change, best done separately. This new coverage in schedlock.exp happens to trigger the internal error in question, like so: FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (1) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (3) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (5) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (7) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (9) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next does not change thread (switched to thread 0) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: current thread advanced - unlocked (wrong amount) That's because we have more than one thread running the same loop, and while one thread is stepping over a function call, the other thread hits the step-resume breakpoint of the first, which needs to be stepped over, and we end up in switch_back_to_stepped_thread exactly in the problem case. I think a simpler and more directed test is also useful, to not rely on internal breakpoint magics. So this commit also adds a test that has a thread trip on a conditional breakpoint that doesn't cause a user-visible stop while another thread is stepping over a call. That currently fails like this: FAIL: gdb.threads/next-bp-other-thread.exp: schedlock=step: next over function call (GDB internal error) Tested on x86_64 Fedora 20. gdb/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * infrun.c (switch_back_to_stepped_thread): Use currently_stepping instead of assuming a thread with a stepping range is always stepping. gdb/testsuite/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * gdb.threads/schedlock.c (some_function): New function. (call_function): New global. (MAYBE_CALL_SOME_FUNCTION): New macro. (thread_function): Call it. * gdb.threads/schedlock.exp (get_args): Add description parameter, and use it instead of a global counter. Adjust all callers. (get_current_thread): Use "find current thread" for test message here rather than having all callers pass down the same string. (goto_loop): New procedure, factored out from ... (my_continue): ... this. (step_ten_loops): Change parameter from test message to command to use. Adjust. (list_count): Delete global. (check_result): New procedure, factored out from duplicate top level code. (continue tests): Wrap in with_test_prefix. (test_step): New procedure, factored out from duplicate top level code. (top level): Test "step" in combination with all scheduler-locking modes. Test "next" in combination with all scheduler-locking modes, and in combination with stepping over a function call or not. * gdb.threads/next-bp-other-thread.c: New file. * gdb.threads/next-bp-other-thread.exp: New file.
2014-10-29 19:15:39 +01:00
set test "listed args ($description)"
gdb_test_multiple "print args" $test {
-re "\\\$\[0-9\]+ = {$pattern}.*$gdb_prompt $" {
PR 17408 - assertion failure in switch_back_to_stepped_thread This PR shows that GDB can easily trigger an assertion here, in infrun.c: 5392 /* Did we find the stepping thread? */ 5393 if (tp->control.step_range_end) 5394 { 5395 /* Yep. There should only one though. */ 5396 gdb_assert (stepping_thread == NULL); 5397 5398 /* The event thread is handled at the top, before we 5399 enter this loop. */ 5400 gdb_assert (tp != ecs->event_thread); 5401 5402 /* If some thread other than the event thread is 5403 stepping, then scheduler locking can't be in effect, 5404 otherwise we wouldn't have resumed the current event 5405 thread in the first place. */ 5406 gdb_assert (!schedlock_applies (currently_stepping (tp))); 5407 5408 stepping_thread = tp; 5409 } Like: gdb/infrun.c:5406: internal-error: switch_back_to_stepped_thread: Assertion `!schedlock_applies (1)' failed. The way the assertion is written is assuming that with schedlock=step we'll always leave threads other than the one with the stepping range locked, while that's not true with the "next" command. With schedlock "step", other threads still run unlocked when "next" detects a function call and steps over it. Whether that makes sense or not, still, it's documented that way in the manual. If another thread hits an event that doesn't cause a stop while the nexting thread steps over a function call, we'll get here and fail the assertion. The fix is just to adjust the assertion. Even though we found the stepping thread, we'll still step-over the breakpoint that just triggered correctly. Surprisingly, gdb.threads/schedlock.exp doesn't have any test that steps over a function call. This commits fixes that. This ensures that "next" doesn't switch focus to another thread, and checks whether other threads run locked or not, depending on scheduler locking mode and command. There's a lot of duplication in that file that this ends cleaning up. There's more that could be cleaned up, but that would end up an unrelated change, best done separately. This new coverage in schedlock.exp happens to trigger the internal error in question, like so: FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (1) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (3) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (5) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (7) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (9) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next does not change thread (switched to thread 0) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: current thread advanced - unlocked (wrong amount) That's because we have more than one thread running the same loop, and while one thread is stepping over a function call, the other thread hits the step-resume breakpoint of the first, which needs to be stepped over, and we end up in switch_back_to_stepped_thread exactly in the problem case. I think a simpler and more directed test is also useful, to not rely on internal breakpoint magics. So this commit also adds a test that has a thread trip on a conditional breakpoint that doesn't cause a user-visible stop while another thread is stepping over a call. That currently fails like this: FAIL: gdb.threads/next-bp-other-thread.exp: schedlock=step: next over function call (GDB internal error) Tested on x86_64 Fedora 20. gdb/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * infrun.c (switch_back_to_stepped_thread): Use currently_stepping instead of assuming a thread with a stepping range is always stepping. gdb/testsuite/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * gdb.threads/schedlock.c (some_function): New function. (call_function): New global. (MAYBE_CALL_SOME_FUNCTION): New macro. (thread_function): Call it. * gdb.threads/schedlock.exp (get_args): Add description parameter, and use it instead of a global counter. Adjust all callers. (get_current_thread): Use "find current thread" for test message here rather than having all callers pass down the same string. (goto_loop): New procedure, factored out from ... (my_continue): ... this. (step_ten_loops): Change parameter from test message to command to use. Adjust. (list_count): Delete global. (check_result): New procedure, factored out from duplicate top level code. (continue tests): Wrap in with_test_prefix. (test_step): New procedure, factored out from duplicate top level code. (top level): Test "step" in combination with all scheduler-locking modes. Test "next" in combination with all scheduler-locking modes, and in combination with stepping over a function call or not. * gdb.threads/next-bp-other-thread.c: New file. * gdb.threads/next-bp-other-thread.exp: New file.
2014-10-29 19:15:39 +01:00
pass $test
set result ""
for {set i 1} {[expr $i <= $NUM]} {incr i} {
lappend result $expect_out($i,string)
}
return $result
}
}
}
proc stop_process { description } {
global gdb_prompt
# For this to work we must be sure to consume the "Continuing."
# message first, or GDB's signal handler may not be in place.
after 1000 {send_gdb "\003"}
gdb_expect {
Fix PR threads/19422 - show which thread caused stop This commit changes GDB like this: - Program received signal SIGINT, Interrupt. + Thread 1 "main" received signal SIGINT, Interrupt. - Breakpoint 1 at 0x40087a: file threads.c, line 87. + Thread 3 "bar" hit Breakpoint 1 at 0x40087a: file threads.c, line 87. ... once the program goes multi-threaded. Until GDB sees a second thread spawn, the output is still the same as before, per the discussion back in 2012: https://www.sourceware.org/ml/gdb/2012-11/msg00010.html This helps non-stop mode, where you can't easily tell which thread hit a breakpoint or received a signal: (gdb) info threads Id Target Id Frame * 1 Thread 0x7ffff7fc1740 (LWP 19362) "main" (running) 2 Thread 0x7ffff7fc0700 (LWP 19366) "foo" (running) 3 Thread 0x7ffff77bf700 (LWP 19367) "bar" (running) (gdb) Program received signal SIGUSR1, User defined signal 1. 0x0000003616a09237 in pthread_join (threadid=140737353877248, thread_return=0x7fffffffd5b8) at pthread_join.c:92 92 lll_wait_tid (pd->tid); (gdb) b threads.c:87 Breakpoint 1 at 0x40087a: file threads.c, line 87. (gdb) Breakpoint 1, thread_function1 (arg=0x1) at threads.c:87 87 usleep (1); /* Loop increment. */ The best the user can do is run "info threads" and try to figure things out. It actually also affects all-stop mode, in case of "handle SIG print nostop": ... Program received signal SIGUSR1, User defined signal 1. Program received signal SIGUSR1, User defined signal 1. Program received signal SIGUSR1, User defined signal 1. Program received signal SIGUSR1, User defined signal 1. ... The above doesn't give any clue that these were different threads getting the SIGUSR1 signal. I initially thought of lowercasing "breakpoint" in "Thread 3 hit Breakpoint 1" but then after trying it I realized that leaving "Breakpoint" uppercase helps the eye quickly find the relevant information. It's also easier to implement not showing anything about threads until the program goes multi-threaded this way. Here's a larger example session in non-stop mode: (gdb) c -a& Continuing. (gdb) interrupt -a (gdb) Thread 1 "main" stopped. 0x0000003616a09237 in pthread_join (threadid=140737353877248, thread_return=0x7fffffffd5b8) at pthread_join.c:92 92 lll_wait_tid (pd->tid); Thread 2 "foo" stopped. 0x0000003615ebc6ed in nanosleep () at ../sysdeps/unix/syscall-template.S:81 81 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS) Thread 3 "bar" stopped. 0x0000003615ebc6ed in nanosleep () at ../sysdeps/unix/syscall-template.S:81 81 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS) b threads.c:87 Breakpoint 4 at 0x40087a: file threads.c, line 87. (gdb) b threads.c:67 Breakpoint 5 at 0x400811: file threads.c, line 67. (gdb) c -a& Continuing. (gdb) Thread 3 "bar" hit Breakpoint 4, thread_function1 (arg=0x1) at threads.c:87 87 usleep (1); /* Loop increment. */ Thread 2 "foo" hit Breakpoint 5, thread_function0 (arg=0x0) at threads.c:68 68 (*myp) ++; info threads Id Target Id Frame * 1 Thread 0x7ffff7fc1740 (LWP 31957) "main" (running) 2 Thread 0x7ffff7fc0700 (LWP 31961) "foo" thread_function0 (arg=0x0) at threads.c:68 3 Thread 0x7ffff77bf700 (LWP 31962) "bar" thread_function1 (arg=0x1) at threads.c:87 (gdb) shell kill -SIGINT 31957 (gdb) Thread 1 "main" received signal SIGINT, Interrupt. 0x0000003616a09237 in pthread_join (threadid=140737353877248, thread_return=0x7fffffffd5b8) at pthread_join.c:92 92 lll_wait_tid (pd->tid); info threads Id Target Id Frame * 1 Thread 0x7ffff7fc1740 (LWP 31957) "main" 0x0000003616a09237 in pthread_join (threadid=140737353877248, thread_return=0x7fffffffd5b8) at pthread_join.c:92 2 Thread 0x7ffff7fc0700 (LWP 31961) "foo" thread_function0 (arg=0x0) at threads.c:68 3 Thread 0x7ffff77bf700 (LWP 31962) "bar" thread_function1 (arg=0x1) at threads.c:87 (gdb) t 2 [Switching to thread 2, Thread 0x7ffff7fc0700 (LWP 31961)] #0 thread_function0 (arg=0x0) at threads.c:68 68 (*myp) ++; (gdb) catch syscall Catchpoint 6 (any syscall) (gdb) c& Continuing. (gdb) Thread 2 "foo" hit Catchpoint 6 (call to syscall nanosleep), 0x0000003615ebc6ed in nanosleep () at ../sysdeps/unix/syscall-template.S:81 81 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS) I'll work on documentation next if this looks agreeable. This patch applies on top of the star wildcards thread IDs series: https://sourceware.org/ml/gdb-patches/2016-01/msg00291.html For convenience, I've pushed this to the users/palves/show-which-thread-caused-stop branch. gdb/doc/ChangeLog: 2016-01-18 Pedro Alves <palves@redhat.com> * gdb.texinfo (Threads): Mention that GDB displays the ID and name of the thread that hit a breakpoint or received a signal. gdb/ChangeLog: 2016-01-18 Pedro Alves <palves@redhat.com> * NEWS: Mention that GDB now displays the ID and name of the thread that hit a breakpoint or received a signal. * break-catch-sig.c (signal_catchpoint_print_it): Use maybe_print_thread_hit_breakpoint. * break-catch-syscall.c (print_it_catch_syscall): Likewise. * break-catch-throw.c (print_it_exception_catchpoint): Likewise. * breakpoint.c (maybe_print_thread_hit_breakpoint): New function. (print_it_catch_fork, print_it_catch_vfork, print_it_catch_solib) (print_it_catch_exec, print_it_ranged_breakpoint) (print_it_watchpoint, print_it_masked_watchpoint, bkpt_print_it): Use maybe_print_thread_hit_breakpoint. * breakpoint.h (maybe_print_thread_hit_breakpoint): Declare. * gdbthread.h (show_thread_that_caused_stop): Declare. * infrun.c (print_signal_received_reason): Print which thread received signal. * thread.c (show_thread_that_caused_stop): New function. gdb/testsuite/ChangeLog: 2016-01-18 Pedro Alves <palves@redhat.com> * gdb.base/async-shell.exp: Adjust expected output. * gdb.base/dprintf-non-stop.exp: Adjust expected output. * gdb.base/siginfo-thread.exp: Adjust expected output. * gdb.base/watchpoint-hw-hit-once.exp: Adjust expected output. * gdb.java/jnpe.exp: Adjust expected output. * gdb.threads/clone-new-thread-event.exp: Adjust expected output. * gdb.threads/continue-pending-status.exp: Adjust expected output. * gdb.threads/leader-exit.exp: Adjust expected output. * gdb.threads/manythreads.exp: Adjust expected output. * gdb.threads/pthreads.exp: Adjust expected output. * gdb.threads/schedlock.exp: Adjust expected output. * gdb.threads/siginfo-threads.exp: Adjust expected output. * gdb.threads/signal-command-multiple-signals-pending.exp: Adjust expected output. * gdb.threads/signal-delivered-right-thread.exp: Adjust expected output. * gdb.threads/sigthread.exp: Adjust expected output. * gdb.threads/watchpoint-fork.exp: Adjust expected output.
2016-01-18 16:15:18 +01:00
-re "Thread .* received signal SIGINT.*$gdb_prompt $"
{
pass $description
}
timeout
{
fail "$description (timeout)"
}
}
}
proc get_current_thread { description } {
global gdb_prompt
PR 17408 - assertion failure in switch_back_to_stepped_thread This PR shows that GDB can easily trigger an assertion here, in infrun.c: 5392 /* Did we find the stepping thread? */ 5393 if (tp->control.step_range_end) 5394 { 5395 /* Yep. There should only one though. */ 5396 gdb_assert (stepping_thread == NULL); 5397 5398 /* The event thread is handled at the top, before we 5399 enter this loop. */ 5400 gdb_assert (tp != ecs->event_thread); 5401 5402 /* If some thread other than the event thread is 5403 stepping, then scheduler locking can't be in effect, 5404 otherwise we wouldn't have resumed the current event 5405 thread in the first place. */ 5406 gdb_assert (!schedlock_applies (currently_stepping (tp))); 5407 5408 stepping_thread = tp; 5409 } Like: gdb/infrun.c:5406: internal-error: switch_back_to_stepped_thread: Assertion `!schedlock_applies (1)' failed. The way the assertion is written is assuming that with schedlock=step we'll always leave threads other than the one with the stepping range locked, while that's not true with the "next" command. With schedlock "step", other threads still run unlocked when "next" detects a function call and steps over it. Whether that makes sense or not, still, it's documented that way in the manual. If another thread hits an event that doesn't cause a stop while the nexting thread steps over a function call, we'll get here and fail the assertion. The fix is just to adjust the assertion. Even though we found the stepping thread, we'll still step-over the breakpoint that just triggered correctly. Surprisingly, gdb.threads/schedlock.exp doesn't have any test that steps over a function call. This commits fixes that. This ensures that "next" doesn't switch focus to another thread, and checks whether other threads run locked or not, depending on scheduler locking mode and command. There's a lot of duplication in that file that this ends cleaning up. There's more that could be cleaned up, but that would end up an unrelated change, best done separately. This new coverage in schedlock.exp happens to trigger the internal error in question, like so: FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (1) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (3) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (5) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (7) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (9) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next does not change thread (switched to thread 0) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: current thread advanced - unlocked (wrong amount) That's because we have more than one thread running the same loop, and while one thread is stepping over a function call, the other thread hits the step-resume breakpoint of the first, which needs to be stepped over, and we end up in switch_back_to_stepped_thread exactly in the problem case. I think a simpler and more directed test is also useful, to not rely on internal breakpoint magics. So this commit also adds a test that has a thread trip on a conditional breakpoint that doesn't cause a user-visible stop while another thread is stepping over a call. That currently fails like this: FAIL: gdb.threads/next-bp-other-thread.exp: schedlock=step: next over function call (GDB internal error) Tested on x86_64 Fedora 20. gdb/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * infrun.c (switch_back_to_stepped_thread): Use currently_stepping instead of assuming a thread with a stepping range is always stepping. gdb/testsuite/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * gdb.threads/schedlock.c (some_function): New function. (call_function): New global. (MAYBE_CALL_SOME_FUNCTION): New macro. (thread_function): Call it. * gdb.threads/schedlock.exp (get_args): Add description parameter, and use it instead of a global counter. Adjust all callers. (get_current_thread): Use "find current thread" for test message here rather than having all callers pass down the same string. (goto_loop): New procedure, factored out from ... (my_continue): ... this. (step_ten_loops): Change parameter from test message to command to use. Adjust. (list_count): Delete global. (check_result): New procedure, factored out from duplicate top level code. (continue tests): Wrap in with_test_prefix. (test_step): New procedure, factored out from duplicate top level code. (top level): Test "step" in combination with all scheduler-locking modes. Test "next" in combination with all scheduler-locking modes, and in combination with stepping over a function call or not. * gdb.threads/next-bp-other-thread.c: New file. * gdb.threads/next-bp-other-thread.exp: New file.
2014-10-29 19:15:39 +01:00
set test "find current thread ($description)"
gdb_test_multiple "bt" $test {
-re "thread_function \\(arg=0x(\[0-9\])\\).*$gdb_prompt $" {
PR 17408 - assertion failure in switch_back_to_stepped_thread This PR shows that GDB can easily trigger an assertion here, in infrun.c: 5392 /* Did we find the stepping thread? */ 5393 if (tp->control.step_range_end) 5394 { 5395 /* Yep. There should only one though. */ 5396 gdb_assert (stepping_thread == NULL); 5397 5398 /* The event thread is handled at the top, before we 5399 enter this loop. */ 5400 gdb_assert (tp != ecs->event_thread); 5401 5402 /* If some thread other than the event thread is 5403 stepping, then scheduler locking can't be in effect, 5404 otherwise we wouldn't have resumed the current event 5405 thread in the first place. */ 5406 gdb_assert (!schedlock_applies (currently_stepping (tp))); 5407 5408 stepping_thread = tp; 5409 } Like: gdb/infrun.c:5406: internal-error: switch_back_to_stepped_thread: Assertion `!schedlock_applies (1)' failed. The way the assertion is written is assuming that with schedlock=step we'll always leave threads other than the one with the stepping range locked, while that's not true with the "next" command. With schedlock "step", other threads still run unlocked when "next" detects a function call and steps over it. Whether that makes sense or not, still, it's documented that way in the manual. If another thread hits an event that doesn't cause a stop while the nexting thread steps over a function call, we'll get here and fail the assertion. The fix is just to adjust the assertion. Even though we found the stepping thread, we'll still step-over the breakpoint that just triggered correctly. Surprisingly, gdb.threads/schedlock.exp doesn't have any test that steps over a function call. This commits fixes that. This ensures that "next" doesn't switch focus to another thread, and checks whether other threads run locked or not, depending on scheduler locking mode and command. There's a lot of duplication in that file that this ends cleaning up. There's more that could be cleaned up, but that would end up an unrelated change, best done separately. This new coverage in schedlock.exp happens to trigger the internal error in question, like so: FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (1) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (3) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (5) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (7) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (9) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next does not change thread (switched to thread 0) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: current thread advanced - unlocked (wrong amount) That's because we have more than one thread running the same loop, and while one thread is stepping over a function call, the other thread hits the step-resume breakpoint of the first, which needs to be stepped over, and we end up in switch_back_to_stepped_thread exactly in the problem case. I think a simpler and more directed test is also useful, to not rely on internal breakpoint magics. So this commit also adds a test that has a thread trip on a conditional breakpoint that doesn't cause a user-visible stop while another thread is stepping over a call. That currently fails like this: FAIL: gdb.threads/next-bp-other-thread.exp: schedlock=step: next over function call (GDB internal error) Tested on x86_64 Fedora 20. gdb/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * infrun.c (switch_back_to_stepped_thread): Use currently_stepping instead of assuming a thread with a stepping range is always stepping. gdb/testsuite/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * gdb.threads/schedlock.c (some_function): New function. (call_function): New global. (MAYBE_CALL_SOME_FUNCTION): New macro. (thread_function): Call it. * gdb.threads/schedlock.exp (get_args): Add description parameter, and use it instead of a global counter. Adjust all callers. (get_current_thread): Use "find current thread" for test message here rather than having all callers pass down the same string. (goto_loop): New procedure, factored out from ... (my_continue): ... this. (step_ten_loops): Change parameter from test message to command to use. Adjust. (list_count): Delete global. (check_result): New procedure, factored out from duplicate top level code. (continue tests): Wrap in with_test_prefix. (test_step): New procedure, factored out from duplicate top level code. (top level): Test "step" in combination with all scheduler-locking modes. Test "next" in combination with all scheduler-locking modes, and in combination with stepping over a function call or not. * gdb.threads/next-bp-other-thread.c: New file. * gdb.threads/next-bp-other-thread.exp: New file.
2014-10-29 19:15:39 +01:00
pass $test
return $expect_out(1,string)
}
}
return ""
}
PR 17408 - assertion failure in switch_back_to_stepped_thread This PR shows that GDB can easily trigger an assertion here, in infrun.c: 5392 /* Did we find the stepping thread? */ 5393 if (tp->control.step_range_end) 5394 { 5395 /* Yep. There should only one though. */ 5396 gdb_assert (stepping_thread == NULL); 5397 5398 /* The event thread is handled at the top, before we 5399 enter this loop. */ 5400 gdb_assert (tp != ecs->event_thread); 5401 5402 /* If some thread other than the event thread is 5403 stepping, then scheduler locking can't be in effect, 5404 otherwise we wouldn't have resumed the current event 5405 thread in the first place. */ 5406 gdb_assert (!schedlock_applies (currently_stepping (tp))); 5407 5408 stepping_thread = tp; 5409 } Like: gdb/infrun.c:5406: internal-error: switch_back_to_stepped_thread: Assertion `!schedlock_applies (1)' failed. The way the assertion is written is assuming that with schedlock=step we'll always leave threads other than the one with the stepping range locked, while that's not true with the "next" command. With schedlock "step", other threads still run unlocked when "next" detects a function call and steps over it. Whether that makes sense or not, still, it's documented that way in the manual. If another thread hits an event that doesn't cause a stop while the nexting thread steps over a function call, we'll get here and fail the assertion. The fix is just to adjust the assertion. Even though we found the stepping thread, we'll still step-over the breakpoint that just triggered correctly. Surprisingly, gdb.threads/schedlock.exp doesn't have any test that steps over a function call. This commits fixes that. This ensures that "next" doesn't switch focus to another thread, and checks whether other threads run locked or not, depending on scheduler locking mode and command. There's a lot of duplication in that file that this ends cleaning up. There's more that could be cleaned up, but that would end up an unrelated change, best done separately. This new coverage in schedlock.exp happens to trigger the internal error in question, like so: FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (1) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (3) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (5) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (7) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (9) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next does not change thread (switched to thread 0) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: current thread advanced - unlocked (wrong amount) That's because we have more than one thread running the same loop, and while one thread is stepping over a function call, the other thread hits the step-resume breakpoint of the first, which needs to be stepped over, and we end up in switch_back_to_stepped_thread exactly in the problem case. I think a simpler and more directed test is also useful, to not rely on internal breakpoint magics. So this commit also adds a test that has a thread trip on a conditional breakpoint that doesn't cause a user-visible stop while another thread is stepping over a call. That currently fails like this: FAIL: gdb.threads/next-bp-other-thread.exp: schedlock=step: next over function call (GDB internal error) Tested on x86_64 Fedora 20. gdb/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * infrun.c (switch_back_to_stepped_thread): Use currently_stepping instead of assuming a thread with a stepping range is always stepping. gdb/testsuite/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * gdb.threads/schedlock.c (some_function): New function. (call_function): New global. (MAYBE_CALL_SOME_FUNCTION): New macro. (thread_function): Call it. * gdb.threads/schedlock.exp (get_args): Add description parameter, and use it instead of a global counter. Adjust all callers. (get_current_thread): Use "find current thread" for test message here rather than having all callers pass down the same string. (goto_loop): New procedure, factored out from ... (my_continue): ... this. (step_ten_loops): Change parameter from test message to command to use. Adjust. (list_count): Delete global. (check_result): New procedure, factored out from duplicate top level code. (continue tests): Wrap in with_test_prefix. (test_step): New procedure, factored out from duplicate top level code. (top level): Test "step" in combination with all scheduler-locking modes. Test "next" in combination with all scheduler-locking modes, and in combination with stepping over a function call or not. * gdb.threads/next-bp-other-thread.c: New file. * gdb.threads/next-bp-other-thread.exp: New file.
2014-10-29 19:15:39 +01:00
# Make sure we're stopped in the loop, in one of the non-main threads.
proc goto_loop { msg } {
gdb_breakpoint [concat [gdb_get_line_number "schedlock.exp: main loop"] " if arg != 0"]
set test "return to loop"
if {$msg != ""} {
set test "$test ($msg)"
}
gdb_continue_to_breakpoint $test
delete_breakpoints
}
proc my_continue { msg } {
PR 17408 - assertion failure in switch_back_to_stepped_thread This PR shows that GDB can easily trigger an assertion here, in infrun.c: 5392 /* Did we find the stepping thread? */ 5393 if (tp->control.step_range_end) 5394 { 5395 /* Yep. There should only one though. */ 5396 gdb_assert (stepping_thread == NULL); 5397 5398 /* The event thread is handled at the top, before we 5399 enter this loop. */ 5400 gdb_assert (tp != ecs->event_thread); 5401 5402 /* If some thread other than the event thread is 5403 stepping, then scheduler locking can't be in effect, 5404 otherwise we wouldn't have resumed the current event 5405 thread in the first place. */ 5406 gdb_assert (!schedlock_applies (currently_stepping (tp))); 5407 5408 stepping_thread = tp; 5409 } Like: gdb/infrun.c:5406: internal-error: switch_back_to_stepped_thread: Assertion `!schedlock_applies (1)' failed. The way the assertion is written is assuming that with schedlock=step we'll always leave threads other than the one with the stepping range locked, while that's not true with the "next" command. With schedlock "step", other threads still run unlocked when "next" detects a function call and steps over it. Whether that makes sense or not, still, it's documented that way in the manual. If another thread hits an event that doesn't cause a stop while the nexting thread steps over a function call, we'll get here and fail the assertion. The fix is just to adjust the assertion. Even though we found the stepping thread, we'll still step-over the breakpoint that just triggered correctly. Surprisingly, gdb.threads/schedlock.exp doesn't have any test that steps over a function call. This commits fixes that. This ensures that "next" doesn't switch focus to another thread, and checks whether other threads run locked or not, depending on scheduler locking mode and command. There's a lot of duplication in that file that this ends cleaning up. There's more that could be cleaned up, but that would end up an unrelated change, best done separately. This new coverage in schedlock.exp happens to trigger the internal error in question, like so: FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (1) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (3) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (5) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (7) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (9) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next does not change thread (switched to thread 0) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: current thread advanced - unlocked (wrong amount) That's because we have more than one thread running the same loop, and while one thread is stepping over a function call, the other thread hits the step-resume breakpoint of the first, which needs to be stepped over, and we end up in switch_back_to_stepped_thread exactly in the problem case. I think a simpler and more directed test is also useful, to not rely on internal breakpoint magics. So this commit also adds a test that has a thread trip on a conditional breakpoint that doesn't cause a user-visible stop while another thread is stepping over a call. That currently fails like this: FAIL: gdb.threads/next-bp-other-thread.exp: schedlock=step: next over function call (GDB internal error) Tested on x86_64 Fedora 20. gdb/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * infrun.c (switch_back_to_stepped_thread): Use currently_stepping instead of assuming a thread with a stepping range is always stepping. gdb/testsuite/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * gdb.threads/schedlock.c (some_function): New function. (call_function): New global. (MAYBE_CALL_SOME_FUNCTION): New macro. (thread_function): Call it. * gdb.threads/schedlock.exp (get_args): Add description parameter, and use it instead of a global counter. Adjust all callers. (get_current_thread): Use "find current thread" for test message here rather than having all callers pass down the same string. (goto_loop): New procedure, factored out from ... (my_continue): ... this. (step_ten_loops): Change parameter from test message to command to use. Adjust. (list_count): Delete global. (check_result): New procedure, factored out from duplicate top level code. (continue tests): Wrap in with_test_prefix. (test_step): New procedure, factored out from duplicate top level code. (top level): Test "step" in combination with all scheduler-locking modes. Test "next" in combination with all scheduler-locking modes, and in combination with stepping over a function call or not. * gdb.threads/next-bp-other-thread.c: New file. * gdb.threads/next-bp-other-thread.exp: New file.
2014-10-29 19:15:39 +01:00
set test "continue ($msg)"
gdb_test_multiple "continue" $test {
-re "Continuing" {
PR 17408 - assertion failure in switch_back_to_stepped_thread This PR shows that GDB can easily trigger an assertion here, in infrun.c: 5392 /* Did we find the stepping thread? */ 5393 if (tp->control.step_range_end) 5394 { 5395 /* Yep. There should only one though. */ 5396 gdb_assert (stepping_thread == NULL); 5397 5398 /* The event thread is handled at the top, before we 5399 enter this loop. */ 5400 gdb_assert (tp != ecs->event_thread); 5401 5402 /* If some thread other than the event thread is 5403 stepping, then scheduler locking can't be in effect, 5404 otherwise we wouldn't have resumed the current event 5405 thread in the first place. */ 5406 gdb_assert (!schedlock_applies (currently_stepping (tp))); 5407 5408 stepping_thread = tp; 5409 } Like: gdb/infrun.c:5406: internal-error: switch_back_to_stepped_thread: Assertion `!schedlock_applies (1)' failed. The way the assertion is written is assuming that with schedlock=step we'll always leave threads other than the one with the stepping range locked, while that's not true with the "next" command. With schedlock "step", other threads still run unlocked when "next" detects a function call and steps over it. Whether that makes sense or not, still, it's documented that way in the manual. If another thread hits an event that doesn't cause a stop while the nexting thread steps over a function call, we'll get here and fail the assertion. The fix is just to adjust the assertion. Even though we found the stepping thread, we'll still step-over the breakpoint that just triggered correctly. Surprisingly, gdb.threads/schedlock.exp doesn't have any test that steps over a function call. This commits fixes that. This ensures that "next" doesn't switch focus to another thread, and checks whether other threads run locked or not, depending on scheduler locking mode and command. There's a lot of duplication in that file that this ends cleaning up. There's more that could be cleaned up, but that would end up an unrelated change, best done separately. This new coverage in schedlock.exp happens to trigger the internal error in question, like so: FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (1) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (3) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (5) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (7) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (9) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next does not change thread (switched to thread 0) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: current thread advanced - unlocked (wrong amount) That's because we have more than one thread running the same loop, and while one thread is stepping over a function call, the other thread hits the step-resume breakpoint of the first, which needs to be stepped over, and we end up in switch_back_to_stepped_thread exactly in the problem case. I think a simpler and more directed test is also useful, to not rely on internal breakpoint magics. So this commit also adds a test that has a thread trip on a conditional breakpoint that doesn't cause a user-visible stop while another thread is stepping over a call. That currently fails like this: FAIL: gdb.threads/next-bp-other-thread.exp: schedlock=step: next over function call (GDB internal error) Tested on x86_64 Fedora 20. gdb/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * infrun.c (switch_back_to_stepped_thread): Use currently_stepping instead of assuming a thread with a stepping range is always stepping. gdb/testsuite/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * gdb.threads/schedlock.c (some_function): New function. (call_function): New global. (MAYBE_CALL_SOME_FUNCTION): New macro. (thread_function): Call it. * gdb.threads/schedlock.exp (get_args): Add description parameter, and use it instead of a global counter. Adjust all callers. (get_current_thread): Use "find current thread" for test message here rather than having all callers pass down the same string. (goto_loop): New procedure, factored out from ... (my_continue): ... this. (step_ten_loops): Change parameter from test message to command to use. Adjust. (list_count): Delete global. (check_result): New procedure, factored out from duplicate top level code. (continue tests): Wrap in with_test_prefix. (test_step): New procedure, factored out from duplicate top level code. (top level): Test "step" in combination with all scheduler-locking modes. Test "next" in combination with all scheduler-locking modes, and in combination with stepping over a function call or not. * gdb.threads/next-bp-other-thread.c: New file. * gdb.threads/next-bp-other-thread.exp: New file.
2014-10-29 19:15:39 +01:00
pass $test
}
}
stop_process "stop all threads ($msg)"
PR 17408 - assertion failure in switch_back_to_stepped_thread This PR shows that GDB can easily trigger an assertion here, in infrun.c: 5392 /* Did we find the stepping thread? */ 5393 if (tp->control.step_range_end) 5394 { 5395 /* Yep. There should only one though. */ 5396 gdb_assert (stepping_thread == NULL); 5397 5398 /* The event thread is handled at the top, before we 5399 enter this loop. */ 5400 gdb_assert (tp != ecs->event_thread); 5401 5402 /* If some thread other than the event thread is 5403 stepping, then scheduler locking can't be in effect, 5404 otherwise we wouldn't have resumed the current event 5405 thread in the first place. */ 5406 gdb_assert (!schedlock_applies (currently_stepping (tp))); 5407 5408 stepping_thread = tp; 5409 } Like: gdb/infrun.c:5406: internal-error: switch_back_to_stepped_thread: Assertion `!schedlock_applies (1)' failed. The way the assertion is written is assuming that with schedlock=step we'll always leave threads other than the one with the stepping range locked, while that's not true with the "next" command. With schedlock "step", other threads still run unlocked when "next" detects a function call and steps over it. Whether that makes sense or not, still, it's documented that way in the manual. If another thread hits an event that doesn't cause a stop while the nexting thread steps over a function call, we'll get here and fail the assertion. The fix is just to adjust the assertion. Even though we found the stepping thread, we'll still step-over the breakpoint that just triggered correctly. Surprisingly, gdb.threads/schedlock.exp doesn't have any test that steps over a function call. This commits fixes that. This ensures that "next" doesn't switch focus to another thread, and checks whether other threads run locked or not, depending on scheduler locking mode and command. There's a lot of duplication in that file that this ends cleaning up. There's more that could be cleaned up, but that would end up an unrelated change, best done separately. This new coverage in schedlock.exp happens to trigger the internal error in question, like so: FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (1) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (3) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (5) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (7) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (9) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next does not change thread (switched to thread 0) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: current thread advanced - unlocked (wrong amount) That's because we have more than one thread running the same loop, and while one thread is stepping over a function call, the other thread hits the step-resume breakpoint of the first, which needs to be stepped over, and we end up in switch_back_to_stepped_thread exactly in the problem case. I think a simpler and more directed test is also useful, to not rely on internal breakpoint magics. So this commit also adds a test that has a thread trip on a conditional breakpoint that doesn't cause a user-visible stop while another thread is stepping over a call. That currently fails like this: FAIL: gdb.threads/next-bp-other-thread.exp: schedlock=step: next over function call (GDB internal error) Tested on x86_64 Fedora 20. gdb/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * infrun.c (switch_back_to_stepped_thread): Use currently_stepping instead of assuming a thread with a stepping range is always stepping. gdb/testsuite/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * gdb.threads/schedlock.c (some_function): New function. (call_function): New global. (MAYBE_CALL_SOME_FUNCTION): New macro. (thread_function): Call it. * gdb.threads/schedlock.exp (get_args): Add description parameter, and use it instead of a global counter. Adjust all callers. (get_current_thread): Use "find current thread" for test message here rather than having all callers pass down the same string. (goto_loop): New procedure, factored out from ... (my_continue): ... this. (step_ten_loops): Change parameter from test message to command to use. Adjust. (list_count): Delete global. (check_result): New procedure, factored out from duplicate top level code. (continue tests): Wrap in with_test_prefix. (test_step): New procedure, factored out from duplicate top level code. (top level): Test "step" in combination with all scheduler-locking modes. Test "next" in combination with all scheduler-locking modes, and in combination with stepping over a function call or not. * gdb.threads/next-bp-other-thread.c: New file. * gdb.threads/next-bp-other-thread.exp: New file.
2014-10-29 19:15:39 +01:00
goto_loop $msg
}
PR 17408 - assertion failure in switch_back_to_stepped_thread This PR shows that GDB can easily trigger an assertion here, in infrun.c: 5392 /* Did we find the stepping thread? */ 5393 if (tp->control.step_range_end) 5394 { 5395 /* Yep. There should only one though. */ 5396 gdb_assert (stepping_thread == NULL); 5397 5398 /* The event thread is handled at the top, before we 5399 enter this loop. */ 5400 gdb_assert (tp != ecs->event_thread); 5401 5402 /* If some thread other than the event thread is 5403 stepping, then scheduler locking can't be in effect, 5404 otherwise we wouldn't have resumed the current event 5405 thread in the first place. */ 5406 gdb_assert (!schedlock_applies (currently_stepping (tp))); 5407 5408 stepping_thread = tp; 5409 } Like: gdb/infrun.c:5406: internal-error: switch_back_to_stepped_thread: Assertion `!schedlock_applies (1)' failed. The way the assertion is written is assuming that with schedlock=step we'll always leave threads other than the one with the stepping range locked, while that's not true with the "next" command. With schedlock "step", other threads still run unlocked when "next" detects a function call and steps over it. Whether that makes sense or not, still, it's documented that way in the manual. If another thread hits an event that doesn't cause a stop while the nexting thread steps over a function call, we'll get here and fail the assertion. The fix is just to adjust the assertion. Even though we found the stepping thread, we'll still step-over the breakpoint that just triggered correctly. Surprisingly, gdb.threads/schedlock.exp doesn't have any test that steps over a function call. This commits fixes that. This ensures that "next" doesn't switch focus to another thread, and checks whether other threads run locked or not, depending on scheduler locking mode and command. There's a lot of duplication in that file that this ends cleaning up. There's more that could be cleaned up, but that would end up an unrelated change, best done separately. This new coverage in schedlock.exp happens to trigger the internal error in question, like so: FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (1) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (3) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (5) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (7) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (9) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next does not change thread (switched to thread 0) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: current thread advanced - unlocked (wrong amount) That's because we have more than one thread running the same loop, and while one thread is stepping over a function call, the other thread hits the step-resume breakpoint of the first, which needs to be stepped over, and we end up in switch_back_to_stepped_thread exactly in the problem case. I think a simpler and more directed test is also useful, to not rely on internal breakpoint magics. So this commit also adds a test that has a thread trip on a conditional breakpoint that doesn't cause a user-visible stop while another thread is stepping over a call. That currently fails like this: FAIL: gdb.threads/next-bp-other-thread.exp: schedlock=step: next over function call (GDB internal error) Tested on x86_64 Fedora 20. gdb/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * infrun.c (switch_back_to_stepped_thread): Use currently_stepping instead of assuming a thread with a stepping range is always stepping. gdb/testsuite/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * gdb.threads/schedlock.c (some_function): New function. (call_function): New global. (MAYBE_CALL_SOME_FUNCTION): New macro. (thread_function): Call it. * gdb.threads/schedlock.exp (get_args): Add description parameter, and use it instead of a global counter. Adjust all callers. (get_current_thread): Use "find current thread" for test message here rather than having all callers pass down the same string. (goto_loop): New procedure, factored out from ... (my_continue): ... this. (step_ten_loops): Change parameter from test message to command to use. Adjust. (list_count): Delete global. (check_result): New procedure, factored out from duplicate top level code. (continue tests): Wrap in with_test_prefix. (test_step): New procedure, factored out from duplicate top level code. (top level): Test "step" in combination with all scheduler-locking modes. Test "next" in combination with all scheduler-locking modes, and in combination with stepping over a function call or not. * gdb.threads/next-bp-other-thread.c: New file. * gdb.threads/next-bp-other-thread.exp: New file.
2014-10-29 19:15:39 +01:00
# Use CMD to step the loop 10 times. CMD may be "step" or "next".
proc step_ten_loops { cmd } {
global gdb_prompt
for {set i 0} {[expr $i < 10]} {set i [expr $i + 1]} {
set other_step 0
PR 17408 - assertion failure in switch_back_to_stepped_thread This PR shows that GDB can easily trigger an assertion here, in infrun.c: 5392 /* Did we find the stepping thread? */ 5393 if (tp->control.step_range_end) 5394 { 5395 /* Yep. There should only one though. */ 5396 gdb_assert (stepping_thread == NULL); 5397 5398 /* The event thread is handled at the top, before we 5399 enter this loop. */ 5400 gdb_assert (tp != ecs->event_thread); 5401 5402 /* If some thread other than the event thread is 5403 stepping, then scheduler locking can't be in effect, 5404 otherwise we wouldn't have resumed the current event 5405 thread in the first place. */ 5406 gdb_assert (!schedlock_applies (currently_stepping (tp))); 5407 5408 stepping_thread = tp; 5409 } Like: gdb/infrun.c:5406: internal-error: switch_back_to_stepped_thread: Assertion `!schedlock_applies (1)' failed. The way the assertion is written is assuming that with schedlock=step we'll always leave threads other than the one with the stepping range locked, while that's not true with the "next" command. With schedlock "step", other threads still run unlocked when "next" detects a function call and steps over it. Whether that makes sense or not, still, it's documented that way in the manual. If another thread hits an event that doesn't cause a stop while the nexting thread steps over a function call, we'll get here and fail the assertion. The fix is just to adjust the assertion. Even though we found the stepping thread, we'll still step-over the breakpoint that just triggered correctly. Surprisingly, gdb.threads/schedlock.exp doesn't have any test that steps over a function call. This commits fixes that. This ensures that "next" doesn't switch focus to another thread, and checks whether other threads run locked or not, depending on scheduler locking mode and command. There's a lot of duplication in that file that this ends cleaning up. There's more that could be cleaned up, but that would end up an unrelated change, best done separately. This new coverage in schedlock.exp happens to trigger the internal error in question, like so: FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (1) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (3) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (5) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (7) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (9) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next does not change thread (switched to thread 0) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: current thread advanced - unlocked (wrong amount) That's because we have more than one thread running the same loop, and while one thread is stepping over a function call, the other thread hits the step-resume breakpoint of the first, which needs to be stepped over, and we end up in switch_back_to_stepped_thread exactly in the problem case. I think a simpler and more directed test is also useful, to not rely on internal breakpoint magics. So this commit also adds a test that has a thread trip on a conditional breakpoint that doesn't cause a user-visible stop while another thread is stepping over a call. That currently fails like this: FAIL: gdb.threads/next-bp-other-thread.exp: schedlock=step: next over function call (GDB internal error) Tested on x86_64 Fedora 20. gdb/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * infrun.c (switch_back_to_stepped_thread): Use currently_stepping instead of assuming a thread with a stepping range is always stepping. gdb/testsuite/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * gdb.threads/schedlock.c (some_function): New function. (call_function): New global. (MAYBE_CALL_SOME_FUNCTION): New macro. (thread_function): Call it. * gdb.threads/schedlock.exp (get_args): Add description parameter, and use it instead of a global counter. Adjust all callers. (get_current_thread): Use "find current thread" for test message here rather than having all callers pass down the same string. (goto_loop): New procedure, factored out from ... (my_continue): ... this. (step_ten_loops): Change parameter from test message to command to use. Adjust. (list_count): Delete global. (check_result): New procedure, factored out from duplicate top level code. (continue tests): Wrap in with_test_prefix. (test_step): New procedure, factored out from duplicate top level code. (top level): Test "step" in combination with all scheduler-locking modes. Test "next" in combination with all scheduler-locking modes, and in combination with stepping over a function call or not. * gdb.threads/next-bp-other-thread.c: New file. * gdb.threads/next-bp-other-thread.exp: New file.
2014-10-29 19:15:39 +01:00
set test "$cmd to increment ($i)"
gdb_test_multiple $cmd $test {
-re ".*myp\\) \\+\\+;\[\r\n\]+$gdb_prompt $" {
PR 17408 - assertion failure in switch_back_to_stepped_thread This PR shows that GDB can easily trigger an assertion here, in infrun.c: 5392 /* Did we find the stepping thread? */ 5393 if (tp->control.step_range_end) 5394 { 5395 /* Yep. There should only one though. */ 5396 gdb_assert (stepping_thread == NULL); 5397 5398 /* The event thread is handled at the top, before we 5399 enter this loop. */ 5400 gdb_assert (tp != ecs->event_thread); 5401 5402 /* If some thread other than the event thread is 5403 stepping, then scheduler locking can't be in effect, 5404 otherwise we wouldn't have resumed the current event 5405 thread in the first place. */ 5406 gdb_assert (!schedlock_applies (currently_stepping (tp))); 5407 5408 stepping_thread = tp; 5409 } Like: gdb/infrun.c:5406: internal-error: switch_back_to_stepped_thread: Assertion `!schedlock_applies (1)' failed. The way the assertion is written is assuming that with schedlock=step we'll always leave threads other than the one with the stepping range locked, while that's not true with the "next" command. With schedlock "step", other threads still run unlocked when "next" detects a function call and steps over it. Whether that makes sense or not, still, it's documented that way in the manual. If another thread hits an event that doesn't cause a stop while the nexting thread steps over a function call, we'll get here and fail the assertion. The fix is just to adjust the assertion. Even though we found the stepping thread, we'll still step-over the breakpoint that just triggered correctly. Surprisingly, gdb.threads/schedlock.exp doesn't have any test that steps over a function call. This commits fixes that. This ensures that "next" doesn't switch focus to another thread, and checks whether other threads run locked or not, depending on scheduler locking mode and command. There's a lot of duplication in that file that this ends cleaning up. There's more that could be cleaned up, but that would end up an unrelated change, best done separately. This new coverage in schedlock.exp happens to trigger the internal error in question, like so: FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (1) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (3) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (5) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (7) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (9) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next does not change thread (switched to thread 0) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: current thread advanced - unlocked (wrong amount) That's because we have more than one thread running the same loop, and while one thread is stepping over a function call, the other thread hits the step-resume breakpoint of the first, which needs to be stepped over, and we end up in switch_back_to_stepped_thread exactly in the problem case. I think a simpler and more directed test is also useful, to not rely on internal breakpoint magics. So this commit also adds a test that has a thread trip on a conditional breakpoint that doesn't cause a user-visible stop while another thread is stepping over a call. That currently fails like this: FAIL: gdb.threads/next-bp-other-thread.exp: schedlock=step: next over function call (GDB internal error) Tested on x86_64 Fedora 20. gdb/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * infrun.c (switch_back_to_stepped_thread): Use currently_stepping instead of assuming a thread with a stepping range is always stepping. gdb/testsuite/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * gdb.threads/schedlock.c (some_function): New function. (call_function): New global. (MAYBE_CALL_SOME_FUNCTION): New macro. (thread_function): Call it. * gdb.threads/schedlock.exp (get_args): Add description parameter, and use it instead of a global counter. Adjust all callers. (get_current_thread): Use "find current thread" for test message here rather than having all callers pass down the same string. (goto_loop): New procedure, factored out from ... (my_continue): ... this. (step_ten_loops): Change parameter from test message to command to use. Adjust. (list_count): Delete global. (check_result): New procedure, factored out from duplicate top level code. (continue tests): Wrap in with_test_prefix. (test_step): New procedure, factored out from duplicate top level code. (top level): Test "step" in combination with all scheduler-locking modes. Test "next" in combination with all scheduler-locking modes, and in combination with stepping over a function call or not. * gdb.threads/next-bp-other-thread.c: New file. * gdb.threads/next-bp-other-thread.exp: New file.
2014-10-29 19:15:39 +01:00
pass $test
}
-re "$gdb_prompt $" {
if {$other_step == 0} {
set other_step 1
PR 17408 - assertion failure in switch_back_to_stepped_thread This PR shows that GDB can easily trigger an assertion here, in infrun.c: 5392 /* Did we find the stepping thread? */ 5393 if (tp->control.step_range_end) 5394 { 5395 /* Yep. There should only one though. */ 5396 gdb_assert (stepping_thread == NULL); 5397 5398 /* The event thread is handled at the top, before we 5399 enter this loop. */ 5400 gdb_assert (tp != ecs->event_thread); 5401 5402 /* If some thread other than the event thread is 5403 stepping, then scheduler locking can't be in effect, 5404 otherwise we wouldn't have resumed the current event 5405 thread in the first place. */ 5406 gdb_assert (!schedlock_applies (currently_stepping (tp))); 5407 5408 stepping_thread = tp; 5409 } Like: gdb/infrun.c:5406: internal-error: switch_back_to_stepped_thread: Assertion `!schedlock_applies (1)' failed. The way the assertion is written is assuming that with schedlock=step we'll always leave threads other than the one with the stepping range locked, while that's not true with the "next" command. With schedlock "step", other threads still run unlocked when "next" detects a function call and steps over it. Whether that makes sense or not, still, it's documented that way in the manual. If another thread hits an event that doesn't cause a stop while the nexting thread steps over a function call, we'll get here and fail the assertion. The fix is just to adjust the assertion. Even though we found the stepping thread, we'll still step-over the breakpoint that just triggered correctly. Surprisingly, gdb.threads/schedlock.exp doesn't have any test that steps over a function call. This commits fixes that. This ensures that "next" doesn't switch focus to another thread, and checks whether other threads run locked or not, depending on scheduler locking mode and command. There's a lot of duplication in that file that this ends cleaning up. There's more that could be cleaned up, but that would end up an unrelated change, best done separately. This new coverage in schedlock.exp happens to trigger the internal error in question, like so: FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (1) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (3) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (5) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (7) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (9) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next does not change thread (switched to thread 0) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: current thread advanced - unlocked (wrong amount) That's because we have more than one thread running the same loop, and while one thread is stepping over a function call, the other thread hits the step-resume breakpoint of the first, which needs to be stepped over, and we end up in switch_back_to_stepped_thread exactly in the problem case. I think a simpler and more directed test is also useful, to not rely on internal breakpoint magics. So this commit also adds a test that has a thread trip on a conditional breakpoint that doesn't cause a user-visible stop while another thread is stepping over a call. That currently fails like this: FAIL: gdb.threads/next-bp-other-thread.exp: schedlock=step: next over function call (GDB internal error) Tested on x86_64 Fedora 20. gdb/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * infrun.c (switch_back_to_stepped_thread): Use currently_stepping instead of assuming a thread with a stepping range is always stepping. gdb/testsuite/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * gdb.threads/schedlock.c (some_function): New function. (call_function): New global. (MAYBE_CALL_SOME_FUNCTION): New macro. (thread_function): Call it. * gdb.threads/schedlock.exp (get_args): Add description parameter, and use it instead of a global counter. Adjust all callers. (get_current_thread): Use "find current thread" for test message here rather than having all callers pass down the same string. (goto_loop): New procedure, factored out from ... (my_continue): ... this. (step_ten_loops): Change parameter from test message to command to use. Adjust. (list_count): Delete global. (check_result): New procedure, factored out from duplicate top level code. (continue tests): Wrap in with_test_prefix. (test_step): New procedure, factored out from duplicate top level code. (top level): Test "step" in combination with all scheduler-locking modes. Test "next" in combination with all scheduler-locking modes, and in combination with stepping over a function call or not. * gdb.threads/next-bp-other-thread.c: New file. * gdb.threads/next-bp-other-thread.exp: New file.
2014-10-29 19:15:39 +01:00
send_gdb "$cmd\n"
exp_continue
} else {
PR 17408 - assertion failure in switch_back_to_stepped_thread This PR shows that GDB can easily trigger an assertion here, in infrun.c: 5392 /* Did we find the stepping thread? */ 5393 if (tp->control.step_range_end) 5394 { 5395 /* Yep. There should only one though. */ 5396 gdb_assert (stepping_thread == NULL); 5397 5398 /* The event thread is handled at the top, before we 5399 enter this loop. */ 5400 gdb_assert (tp != ecs->event_thread); 5401 5402 /* If some thread other than the event thread is 5403 stepping, then scheduler locking can't be in effect, 5404 otherwise we wouldn't have resumed the current event 5405 thread in the first place. */ 5406 gdb_assert (!schedlock_applies (currently_stepping (tp))); 5407 5408 stepping_thread = tp; 5409 } Like: gdb/infrun.c:5406: internal-error: switch_back_to_stepped_thread: Assertion `!schedlock_applies (1)' failed. The way the assertion is written is assuming that with schedlock=step we'll always leave threads other than the one with the stepping range locked, while that's not true with the "next" command. With schedlock "step", other threads still run unlocked when "next" detects a function call and steps over it. Whether that makes sense or not, still, it's documented that way in the manual. If another thread hits an event that doesn't cause a stop while the nexting thread steps over a function call, we'll get here and fail the assertion. The fix is just to adjust the assertion. Even though we found the stepping thread, we'll still step-over the breakpoint that just triggered correctly. Surprisingly, gdb.threads/schedlock.exp doesn't have any test that steps over a function call. This commits fixes that. This ensures that "next" doesn't switch focus to another thread, and checks whether other threads run locked or not, depending on scheduler locking mode and command. There's a lot of duplication in that file that this ends cleaning up. There's more that could be cleaned up, but that would end up an unrelated change, best done separately. This new coverage in schedlock.exp happens to trigger the internal error in question, like so: FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (1) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (3) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (5) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (7) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (9) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next does not change thread (switched to thread 0) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: current thread advanced - unlocked (wrong amount) That's because we have more than one thread running the same loop, and while one thread is stepping over a function call, the other thread hits the step-resume breakpoint of the first, which needs to be stepped over, and we end up in switch_back_to_stepped_thread exactly in the problem case. I think a simpler and more directed test is also useful, to not rely on internal breakpoint magics. So this commit also adds a test that has a thread trip on a conditional breakpoint that doesn't cause a user-visible stop while another thread is stepping over a call. That currently fails like this: FAIL: gdb.threads/next-bp-other-thread.exp: schedlock=step: next over function call (GDB internal error) Tested on x86_64 Fedora 20. gdb/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * infrun.c (switch_back_to_stepped_thread): Use currently_stepping instead of assuming a thread with a stepping range is always stepping. gdb/testsuite/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * gdb.threads/schedlock.c (some_function): New function. (call_function): New global. (MAYBE_CALL_SOME_FUNCTION): New macro. (thread_function): Call it. * gdb.threads/schedlock.exp (get_args): Add description parameter, and use it instead of a global counter. Adjust all callers. (get_current_thread): Use "find current thread" for test message here rather than having all callers pass down the same string. (goto_loop): New procedure, factored out from ... (my_continue): ... this. (step_ten_loops): Change parameter from test message to command to use. Adjust. (list_count): Delete global. (check_result): New procedure, factored out from duplicate top level code. (continue tests): Wrap in with_test_prefix. (test_step): New procedure, factored out from duplicate top level code. (top level): Test "step" in combination with all scheduler-locking modes. Test "next" in combination with all scheduler-locking modes, and in combination with stepping over a function call or not. * gdb.threads/next-bp-other-thread.c: New file. * gdb.threads/next-bp-other-thread.exp: New file.
2014-10-29 19:15:39 +01:00
fail $test
# FIXME cascade?
}
}
}
}
}
# Start with a fresh gdb.
gdb_exit
gdb_start
gdb_reinitialize_dir $srcdir/$subdir
# We'll need this when we send_gdb a ^C to GDB. Need to do it before we
# run the program and gdb starts saving and restoring tty states.
gdb_test "shell stty intr '^C'" ".*"
gdb_load ${binfile}
gdb_test_no_output "set print sevenbit-strings"
gdb_test_no_output "set width 0"
runto_main
# See if scheduler locking is available on this target.
global gdb_prompt
gdb_test_multiple "set scheduler-locking off" "scheduler locking set to none" {
-re "Target .* cannot support this command" {
unsupported "target does not support scheduler locking"
return
}
-re "$gdb_prompt $" {
pass "scheduler locking set to none"
}
timeout {
unsupported "target does not support scheduler locking (timeout)"
return
}
}
gdb_breakpoint [gdb_get_line_number "schedlock.exp: last thread start"]
gdb_continue_to_breakpoint "all threads started"
PR 17408 - assertion failure in switch_back_to_stepped_thread This PR shows that GDB can easily trigger an assertion here, in infrun.c: 5392 /* Did we find the stepping thread? */ 5393 if (tp->control.step_range_end) 5394 { 5395 /* Yep. There should only one though. */ 5396 gdb_assert (stepping_thread == NULL); 5397 5398 /* The event thread is handled at the top, before we 5399 enter this loop. */ 5400 gdb_assert (tp != ecs->event_thread); 5401 5402 /* If some thread other than the event thread is 5403 stepping, then scheduler locking can't be in effect, 5404 otherwise we wouldn't have resumed the current event 5405 thread in the first place. */ 5406 gdb_assert (!schedlock_applies (currently_stepping (tp))); 5407 5408 stepping_thread = tp; 5409 } Like: gdb/infrun.c:5406: internal-error: switch_back_to_stepped_thread: Assertion `!schedlock_applies (1)' failed. The way the assertion is written is assuming that with schedlock=step we'll always leave threads other than the one with the stepping range locked, while that's not true with the "next" command. With schedlock "step", other threads still run unlocked when "next" detects a function call and steps over it. Whether that makes sense or not, still, it's documented that way in the manual. If another thread hits an event that doesn't cause a stop while the nexting thread steps over a function call, we'll get here and fail the assertion. The fix is just to adjust the assertion. Even though we found the stepping thread, we'll still step-over the breakpoint that just triggered correctly. Surprisingly, gdb.threads/schedlock.exp doesn't have any test that steps over a function call. This commits fixes that. This ensures that "next" doesn't switch focus to another thread, and checks whether other threads run locked or not, depending on scheduler locking mode and command. There's a lot of duplication in that file that this ends cleaning up. There's more that could be cleaned up, but that would end up an unrelated change, best done separately. This new coverage in schedlock.exp happens to trigger the internal error in question, like so: FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (1) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (3) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (5) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (7) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (9) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next does not change thread (switched to thread 0) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: current thread advanced - unlocked (wrong amount) That's because we have more than one thread running the same loop, and while one thread is stepping over a function call, the other thread hits the step-resume breakpoint of the first, which needs to be stepped over, and we end up in switch_back_to_stepped_thread exactly in the problem case. I think a simpler and more directed test is also useful, to not rely on internal breakpoint magics. So this commit also adds a test that has a thread trip on a conditional breakpoint that doesn't cause a user-visible stop while another thread is stepping over a call. That currently fails like this: FAIL: gdb.threads/next-bp-other-thread.exp: schedlock=step: next over function call (GDB internal error) Tested on x86_64 Fedora 20. gdb/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * infrun.c (switch_back_to_stepped_thread): Use currently_stepping instead of assuming a thread with a stepping range is always stepping. gdb/testsuite/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * gdb.threads/schedlock.c (some_function): New function. (call_function): New global. (MAYBE_CALL_SOME_FUNCTION): New macro. (thread_function): Call it. * gdb.threads/schedlock.exp (get_args): Add description parameter, and use it instead of a global counter. Adjust all callers. (get_current_thread): Use "find current thread" for test message here rather than having all callers pass down the same string. (goto_loop): New procedure, factored out from ... (my_continue): ... this. (step_ten_loops): Change parameter from test message to command to use. Adjust. (list_count): Delete global. (check_result): New procedure, factored out from duplicate top level code. (continue tests): Wrap in with_test_prefix. (test_step): New procedure, factored out from duplicate top level code. (top level): Test "step" in combination with all scheduler-locking modes. Test "next" in combination with all scheduler-locking modes, and in combination with stepping over a function call or not. * gdb.threads/next-bp-other-thread.c: New file. * gdb.threads/next-bp-other-thread.exp: New file.
2014-10-29 19:15:39 +01:00
set start_args [get_args "before initial"]
# First make sure that all threads are alive.
my_continue "initial"
PR 17408 - assertion failure in switch_back_to_stepped_thread This PR shows that GDB can easily trigger an assertion here, in infrun.c: 5392 /* Did we find the stepping thread? */ 5393 if (tp->control.step_range_end) 5394 { 5395 /* Yep. There should only one though. */ 5396 gdb_assert (stepping_thread == NULL); 5397 5398 /* The event thread is handled at the top, before we 5399 enter this loop. */ 5400 gdb_assert (tp != ecs->event_thread); 5401 5402 /* If some thread other than the event thread is 5403 stepping, then scheduler locking can't be in effect, 5404 otherwise we wouldn't have resumed the current event 5405 thread in the first place. */ 5406 gdb_assert (!schedlock_applies (currently_stepping (tp))); 5407 5408 stepping_thread = tp; 5409 } Like: gdb/infrun.c:5406: internal-error: switch_back_to_stepped_thread: Assertion `!schedlock_applies (1)' failed. The way the assertion is written is assuming that with schedlock=step we'll always leave threads other than the one with the stepping range locked, while that's not true with the "next" command. With schedlock "step", other threads still run unlocked when "next" detects a function call and steps over it. Whether that makes sense or not, still, it's documented that way in the manual. If another thread hits an event that doesn't cause a stop while the nexting thread steps over a function call, we'll get here and fail the assertion. The fix is just to adjust the assertion. Even though we found the stepping thread, we'll still step-over the breakpoint that just triggered correctly. Surprisingly, gdb.threads/schedlock.exp doesn't have any test that steps over a function call. This commits fixes that. This ensures that "next" doesn't switch focus to another thread, and checks whether other threads run locked or not, depending on scheduler locking mode and command. There's a lot of duplication in that file that this ends cleaning up. There's more that could be cleaned up, but that would end up an unrelated change, best done separately. This new coverage in schedlock.exp happens to trigger the internal error in question, like so: FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (1) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (3) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (5) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (7) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (9) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next does not change thread (switched to thread 0) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: current thread advanced - unlocked (wrong amount) That's because we have more than one thread running the same loop, and while one thread is stepping over a function call, the other thread hits the step-resume breakpoint of the first, which needs to be stepped over, and we end up in switch_back_to_stepped_thread exactly in the problem case. I think a simpler and more directed test is also useful, to not rely on internal breakpoint magics. So this commit also adds a test that has a thread trip on a conditional breakpoint that doesn't cause a user-visible stop while another thread is stepping over a call. That currently fails like this: FAIL: gdb.threads/next-bp-other-thread.exp: schedlock=step: next over function call (GDB internal error) Tested on x86_64 Fedora 20. gdb/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * infrun.c (switch_back_to_stepped_thread): Use currently_stepping instead of assuming a thread with a stepping range is always stepping. gdb/testsuite/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * gdb.threads/schedlock.c (some_function): New function. (call_function): New global. (MAYBE_CALL_SOME_FUNCTION): New macro. (thread_function): Call it. * gdb.threads/schedlock.exp (get_args): Add description parameter, and use it instead of a global counter. Adjust all callers. (get_current_thread): Use "find current thread" for test message here rather than having all callers pass down the same string. (goto_loop): New procedure, factored out from ... (my_continue): ... this. (step_ten_loops): Change parameter from test message to command to use. Adjust. (list_count): Delete global. (check_result): New procedure, factored out from duplicate top level code. (continue tests): Wrap in with_test_prefix. (test_step): New procedure, factored out from duplicate top level code. (top level): Test "step" in combination with all scheduler-locking modes. Test "next" in combination with all scheduler-locking modes, and in combination with stepping over a function call or not. * gdb.threads/next-bp-other-thread.c: New file. * gdb.threads/next-bp-other-thread.exp: New file.
2014-10-29 19:15:39 +01:00
set cont_args [get_args "after initial"]
set bad 0
for {set i 0} {[expr $i < $NUM]} {set i [expr $i + 1]} {
if {[lindex $start_args $i] == [lindex $cont_args $i]} {
incr bad
}
}
if { $bad == 0 } {
pass "all threads alive"
} else {
fail "all threads alive ($bad/$NUM did not run)"
}
PR 17408 - assertion failure in switch_back_to_stepped_thread This PR shows that GDB can easily trigger an assertion here, in infrun.c: 5392 /* Did we find the stepping thread? */ 5393 if (tp->control.step_range_end) 5394 { 5395 /* Yep. There should only one though. */ 5396 gdb_assert (stepping_thread == NULL); 5397 5398 /* The event thread is handled at the top, before we 5399 enter this loop. */ 5400 gdb_assert (tp != ecs->event_thread); 5401 5402 /* If some thread other than the event thread is 5403 stepping, then scheduler locking can't be in effect, 5404 otherwise we wouldn't have resumed the current event 5405 thread in the first place. */ 5406 gdb_assert (!schedlock_applies (currently_stepping (tp))); 5407 5408 stepping_thread = tp; 5409 } Like: gdb/infrun.c:5406: internal-error: switch_back_to_stepped_thread: Assertion `!schedlock_applies (1)' failed. The way the assertion is written is assuming that with schedlock=step we'll always leave threads other than the one with the stepping range locked, while that's not true with the "next" command. With schedlock "step", other threads still run unlocked when "next" detects a function call and steps over it. Whether that makes sense or not, still, it's documented that way in the manual. If another thread hits an event that doesn't cause a stop while the nexting thread steps over a function call, we'll get here and fail the assertion. The fix is just to adjust the assertion. Even though we found the stepping thread, we'll still step-over the breakpoint that just triggered correctly. Surprisingly, gdb.threads/schedlock.exp doesn't have any test that steps over a function call. This commits fixes that. This ensures that "next" doesn't switch focus to another thread, and checks whether other threads run locked or not, depending on scheduler locking mode and command. There's a lot of duplication in that file that this ends cleaning up. There's more that could be cleaned up, but that would end up an unrelated change, best done separately. This new coverage in schedlock.exp happens to trigger the internal error in question, like so: FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (1) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (3) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (5) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (7) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (9) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next does not change thread (switched to thread 0) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: current thread advanced - unlocked (wrong amount) That's because we have more than one thread running the same loop, and while one thread is stepping over a function call, the other thread hits the step-resume breakpoint of the first, which needs to be stepped over, and we end up in switch_back_to_stepped_thread exactly in the problem case. I think a simpler and more directed test is also useful, to not rely on internal breakpoint magics. So this commit also adds a test that has a thread trip on a conditional breakpoint that doesn't cause a user-visible stop while another thread is stepping over a call. That currently fails like this: FAIL: gdb.threads/next-bp-other-thread.exp: schedlock=step: next over function call (GDB internal error) Tested on x86_64 Fedora 20. gdb/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * infrun.c (switch_back_to_stepped_thread): Use currently_stepping instead of assuming a thread with a stepping range is always stepping. gdb/testsuite/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * gdb.threads/schedlock.c (some_function): New function. (call_function): New global. (MAYBE_CALL_SOME_FUNCTION): New macro. (thread_function): Call it. * gdb.threads/schedlock.exp (get_args): Add description parameter, and use it instead of a global counter. Adjust all callers. (get_current_thread): Use "find current thread" for test message here rather than having all callers pass down the same string. (goto_loop): New procedure, factored out from ... (my_continue): ... this. (step_ten_loops): Change parameter from test message to command to use. Adjust. (list_count): Delete global. (check_result): New procedure, factored out from duplicate top level code. (continue tests): Wrap in with_test_prefix. (test_step): New procedure, factored out from duplicate top level code. (top level): Test "step" in combination with all scheduler-locking modes. Test "next" in combination with all scheduler-locking modes, and in combination with stepping over a function call or not. * gdb.threads/next-bp-other-thread.c: New file. * gdb.threads/next-bp-other-thread.exp: New file.
2014-10-29 19:15:39 +01:00
# Compare the previous thread and args with the current thread and
# args. Check that we didn't switch threads, and that the threads
# incremented their args counter the amounts expected. CMD is the
# command being tested. BEFORE_THREAD is the thread that was selected
# before the command was run. BEFORE_ARGS is the value of the
# thread's args before the command was run. LOCKED indicates whether
# we expect threads other than the selected thread remained locked.
PR 17408 - assertion failure in switch_back_to_stepped_thread This PR shows that GDB can easily trigger an assertion here, in infrun.c: 5392 /* Did we find the stepping thread? */ 5393 if (tp->control.step_range_end) 5394 { 5395 /* Yep. There should only one though. */ 5396 gdb_assert (stepping_thread == NULL); 5397 5398 /* The event thread is handled at the top, before we 5399 enter this loop. */ 5400 gdb_assert (tp != ecs->event_thread); 5401 5402 /* If some thread other than the event thread is 5403 stepping, then scheduler locking can't be in effect, 5404 otherwise we wouldn't have resumed the current event 5405 thread in the first place. */ 5406 gdb_assert (!schedlock_applies (currently_stepping (tp))); 5407 5408 stepping_thread = tp; 5409 } Like: gdb/infrun.c:5406: internal-error: switch_back_to_stepped_thread: Assertion `!schedlock_applies (1)' failed. The way the assertion is written is assuming that with schedlock=step we'll always leave threads other than the one with the stepping range locked, while that's not true with the "next" command. With schedlock "step", other threads still run unlocked when "next" detects a function call and steps over it. Whether that makes sense or not, still, it's documented that way in the manual. If another thread hits an event that doesn't cause a stop while the nexting thread steps over a function call, we'll get here and fail the assertion. The fix is just to adjust the assertion. Even though we found the stepping thread, we'll still step-over the breakpoint that just triggered correctly. Surprisingly, gdb.threads/schedlock.exp doesn't have any test that steps over a function call. This commits fixes that. This ensures that "next" doesn't switch focus to another thread, and checks whether other threads run locked or not, depending on scheduler locking mode and command. There's a lot of duplication in that file that this ends cleaning up. There's more that could be cleaned up, but that would end up an unrelated change, best done separately. This new coverage in schedlock.exp happens to trigger the internal error in question, like so: FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (1) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (3) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (5) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (7) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (9) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next does not change thread (switched to thread 0) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: current thread advanced - unlocked (wrong amount) That's because we have more than one thread running the same loop, and while one thread is stepping over a function call, the other thread hits the step-resume breakpoint of the first, which needs to be stepped over, and we end up in switch_back_to_stepped_thread exactly in the problem case. I think a simpler and more directed test is also useful, to not rely on internal breakpoint magics. So this commit also adds a test that has a thread trip on a conditional breakpoint that doesn't cause a user-visible stop while another thread is stepping over a call. That currently fails like this: FAIL: gdb.threads/next-bp-other-thread.exp: schedlock=step: next over function call (GDB internal error) Tested on x86_64 Fedora 20. gdb/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * infrun.c (switch_back_to_stepped_thread): Use currently_stepping instead of assuming a thread with a stepping range is always stepping. gdb/testsuite/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * gdb.threads/schedlock.c (some_function): New function. (call_function): New global. (MAYBE_CALL_SOME_FUNCTION): New macro. (thread_function): Call it. * gdb.threads/schedlock.exp (get_args): Add description parameter, and use it instead of a global counter. Adjust all callers. (get_current_thread): Use "find current thread" for test message here rather than having all callers pass down the same string. (goto_loop): New procedure, factored out from ... (my_continue): ... this. (step_ten_loops): Change parameter from test message to command to use. Adjust. (list_count): Delete global. (check_result): New procedure, factored out from duplicate top level code. (continue tests): Wrap in with_test_prefix. (test_step): New procedure, factored out from duplicate top level code. (top level): Test "step" in combination with all scheduler-locking modes. Test "next" in combination with all scheduler-locking modes, and in combination with stepping over a function call or not. * gdb.threads/next-bp-other-thread.c: New file. * gdb.threads/next-bp-other-thread.exp: New file.
2014-10-29 19:15:39 +01:00
proc check_result { cmd before_thread before_args locked } {
global NUM
PR 17408 - assertion failure in switch_back_to_stepped_thread This PR shows that GDB can easily trigger an assertion here, in infrun.c: 5392 /* Did we find the stepping thread? */ 5393 if (tp->control.step_range_end) 5394 { 5395 /* Yep. There should only one though. */ 5396 gdb_assert (stepping_thread == NULL); 5397 5398 /* The event thread is handled at the top, before we 5399 enter this loop. */ 5400 gdb_assert (tp != ecs->event_thread); 5401 5402 /* If some thread other than the event thread is 5403 stepping, then scheduler locking can't be in effect, 5404 otherwise we wouldn't have resumed the current event 5405 thread in the first place. */ 5406 gdb_assert (!schedlock_applies (currently_stepping (tp))); 5407 5408 stepping_thread = tp; 5409 } Like: gdb/infrun.c:5406: internal-error: switch_back_to_stepped_thread: Assertion `!schedlock_applies (1)' failed. The way the assertion is written is assuming that with schedlock=step we'll always leave threads other than the one with the stepping range locked, while that's not true with the "next" command. With schedlock "step", other threads still run unlocked when "next" detects a function call and steps over it. Whether that makes sense or not, still, it's documented that way in the manual. If another thread hits an event that doesn't cause a stop while the nexting thread steps over a function call, we'll get here and fail the assertion. The fix is just to adjust the assertion. Even though we found the stepping thread, we'll still step-over the breakpoint that just triggered correctly. Surprisingly, gdb.threads/schedlock.exp doesn't have any test that steps over a function call. This commits fixes that. This ensures that "next" doesn't switch focus to another thread, and checks whether other threads run locked or not, depending on scheduler locking mode and command. There's a lot of duplication in that file that this ends cleaning up. There's more that could be cleaned up, but that would end up an unrelated change, best done separately. This new coverage in schedlock.exp happens to trigger the internal error in question, like so: FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (1) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (3) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (5) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (7) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (9) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next does not change thread (switched to thread 0) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: current thread advanced - unlocked (wrong amount) That's because we have more than one thread running the same loop, and while one thread is stepping over a function call, the other thread hits the step-resume breakpoint of the first, which needs to be stepped over, and we end up in switch_back_to_stepped_thread exactly in the problem case. I think a simpler and more directed test is also useful, to not rely on internal breakpoint magics. So this commit also adds a test that has a thread trip on a conditional breakpoint that doesn't cause a user-visible stop while another thread is stepping over a call. That currently fails like this: FAIL: gdb.threads/next-bp-other-thread.exp: schedlock=step: next over function call (GDB internal error) Tested on x86_64 Fedora 20. gdb/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * infrun.c (switch_back_to_stepped_thread): Use currently_stepping instead of assuming a thread with a stepping range is always stepping. gdb/testsuite/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * gdb.threads/schedlock.c (some_function): New function. (call_function): New global. (MAYBE_CALL_SOME_FUNCTION): New macro. (thread_function): Call it. * gdb.threads/schedlock.exp (get_args): Add description parameter, and use it instead of a global counter. Adjust all callers. (get_current_thread): Use "find current thread" for test message here rather than having all callers pass down the same string. (goto_loop): New procedure, factored out from ... (my_continue): ... this. (step_ten_loops): Change parameter from test message to command to use. Adjust. (list_count): Delete global. (check_result): New procedure, factored out from duplicate top level code. (continue tests): Wrap in with_test_prefix. (test_step): New procedure, factored out from duplicate top level code. (top level): Test "step" in combination with all scheduler-locking modes. Test "next" in combination with all scheduler-locking modes, and in combination with stepping over a function call or not. * gdb.threads/next-bp-other-thread.c: New file. * gdb.threads/next-bp-other-thread.exp: New file.
2014-10-29 19:15:39 +01:00
# Make sure we're still in the same thread.
set newthread [get_current_thread "after"]
PR 17408 - assertion failure in switch_back_to_stepped_thread This PR shows that GDB can easily trigger an assertion here, in infrun.c: 5392 /* Did we find the stepping thread? */ 5393 if (tp->control.step_range_end) 5394 { 5395 /* Yep. There should only one though. */ 5396 gdb_assert (stepping_thread == NULL); 5397 5398 /* The event thread is handled at the top, before we 5399 enter this loop. */ 5400 gdb_assert (tp != ecs->event_thread); 5401 5402 /* If some thread other than the event thread is 5403 stepping, then scheduler locking can't be in effect, 5404 otherwise we wouldn't have resumed the current event 5405 thread in the first place. */ 5406 gdb_assert (!schedlock_applies (currently_stepping (tp))); 5407 5408 stepping_thread = tp; 5409 } Like: gdb/infrun.c:5406: internal-error: switch_back_to_stepped_thread: Assertion `!schedlock_applies (1)' failed. The way the assertion is written is assuming that with schedlock=step we'll always leave threads other than the one with the stepping range locked, while that's not true with the "next" command. With schedlock "step", other threads still run unlocked when "next" detects a function call and steps over it. Whether that makes sense or not, still, it's documented that way in the manual. If another thread hits an event that doesn't cause a stop while the nexting thread steps over a function call, we'll get here and fail the assertion. The fix is just to adjust the assertion. Even though we found the stepping thread, we'll still step-over the breakpoint that just triggered correctly. Surprisingly, gdb.threads/schedlock.exp doesn't have any test that steps over a function call. This commits fixes that. This ensures that "next" doesn't switch focus to another thread, and checks whether other threads run locked or not, depending on scheduler locking mode and command. There's a lot of duplication in that file that this ends cleaning up. There's more that could be cleaned up, but that would end up an unrelated change, best done separately. This new coverage in schedlock.exp happens to trigger the internal error in question, like so: FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (1) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (3) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (5) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (7) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (9) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next does not change thread (switched to thread 0) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: current thread advanced - unlocked (wrong amount) That's because we have more than one thread running the same loop, and while one thread is stepping over a function call, the other thread hits the step-resume breakpoint of the first, which needs to be stepped over, and we end up in switch_back_to_stepped_thread exactly in the problem case. I think a simpler and more directed test is also useful, to not rely on internal breakpoint magics. So this commit also adds a test that has a thread trip on a conditional breakpoint that doesn't cause a user-visible stop while another thread is stepping over a call. That currently fails like this: FAIL: gdb.threads/next-bp-other-thread.exp: schedlock=step: next over function call (GDB internal error) Tested on x86_64 Fedora 20. gdb/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * infrun.c (switch_back_to_stepped_thread): Use currently_stepping instead of assuming a thread with a stepping range is always stepping. gdb/testsuite/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * gdb.threads/schedlock.c (some_function): New function. (call_function): New global. (MAYBE_CALL_SOME_FUNCTION): New macro. (thread_function): Call it. * gdb.threads/schedlock.exp (get_args): Add description parameter, and use it instead of a global counter. Adjust all callers. (get_current_thread): Use "find current thread" for test message here rather than having all callers pass down the same string. (goto_loop): New procedure, factored out from ... (my_continue): ... this. (step_ten_loops): Change parameter from test message to command to use. Adjust. (list_count): Delete global. (check_result): New procedure, factored out from duplicate top level code. (continue tests): Wrap in with_test_prefix. (test_step): New procedure, factored out from duplicate top level code. (top level): Test "step" in combination with all scheduler-locking modes. Test "next" in combination with all scheduler-locking modes, and in combination with stepping over a function call or not. * gdb.threads/next-bp-other-thread.c: New file. * gdb.threads/next-bp-other-thread.exp: New file.
2014-10-29 19:15:39 +01:00
set test "$cmd does not change thread"
if {$before_thread == $newthread} {
pass "$test"
} else {
fail "$test (switched to thread $newthread)"
}
PR 17408 - assertion failure in switch_back_to_stepped_thread This PR shows that GDB can easily trigger an assertion here, in infrun.c: 5392 /* Did we find the stepping thread? */ 5393 if (tp->control.step_range_end) 5394 { 5395 /* Yep. There should only one though. */ 5396 gdb_assert (stepping_thread == NULL); 5397 5398 /* The event thread is handled at the top, before we 5399 enter this loop. */ 5400 gdb_assert (tp != ecs->event_thread); 5401 5402 /* If some thread other than the event thread is 5403 stepping, then scheduler locking can't be in effect, 5404 otherwise we wouldn't have resumed the current event 5405 thread in the first place. */ 5406 gdb_assert (!schedlock_applies (currently_stepping (tp))); 5407 5408 stepping_thread = tp; 5409 } Like: gdb/infrun.c:5406: internal-error: switch_back_to_stepped_thread: Assertion `!schedlock_applies (1)' failed. The way the assertion is written is assuming that with schedlock=step we'll always leave threads other than the one with the stepping range locked, while that's not true with the "next" command. With schedlock "step", other threads still run unlocked when "next" detects a function call and steps over it. Whether that makes sense or not, still, it's documented that way in the manual. If another thread hits an event that doesn't cause a stop while the nexting thread steps over a function call, we'll get here and fail the assertion. The fix is just to adjust the assertion. Even though we found the stepping thread, we'll still step-over the breakpoint that just triggered correctly. Surprisingly, gdb.threads/schedlock.exp doesn't have any test that steps over a function call. This commits fixes that. This ensures that "next" doesn't switch focus to another thread, and checks whether other threads run locked or not, depending on scheduler locking mode and command. There's a lot of duplication in that file that this ends cleaning up. There's more that could be cleaned up, but that would end up an unrelated change, best done separately. This new coverage in schedlock.exp happens to trigger the internal error in question, like so: FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (1) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (3) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (5) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (7) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (9) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next does not change thread (switched to thread 0) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: current thread advanced - unlocked (wrong amount) That's because we have more than one thread running the same loop, and while one thread is stepping over a function call, the other thread hits the step-resume breakpoint of the first, which needs to be stepped over, and we end up in switch_back_to_stepped_thread exactly in the problem case. I think a simpler and more directed test is also useful, to not rely on internal breakpoint magics. So this commit also adds a test that has a thread trip on a conditional breakpoint that doesn't cause a user-visible stop while another thread is stepping over a call. That currently fails like this: FAIL: gdb.threads/next-bp-other-thread.exp: schedlock=step: next over function call (GDB internal error) Tested on x86_64 Fedora 20. gdb/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * infrun.c (switch_back_to_stepped_thread): Use currently_stepping instead of assuming a thread with a stepping range is always stepping. gdb/testsuite/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * gdb.threads/schedlock.c (some_function): New function. (call_function): New global. (MAYBE_CALL_SOME_FUNCTION): New macro. (thread_function): Call it. * gdb.threads/schedlock.exp (get_args): Add description parameter, and use it instead of a global counter. Adjust all callers. (get_current_thread): Use "find current thread" for test message here rather than having all callers pass down the same string. (goto_loop): New procedure, factored out from ... (my_continue): ... this. (step_ten_loops): Change parameter from test message to command to use. Adjust. (list_count): Delete global. (check_result): New procedure, factored out from duplicate top level code. (continue tests): Wrap in with_test_prefix. (test_step): New procedure, factored out from duplicate top level code. (top level): Test "step" in combination with all scheduler-locking modes. Test "next" in combination with all scheduler-locking modes, and in combination with stepping over a function call or not. * gdb.threads/next-bp-other-thread.c: New file. * gdb.threads/next-bp-other-thread.exp: New file.
2014-10-29 19:15:39 +01:00
set after_args [get_args "after"]
PR 17408 - assertion failure in switch_back_to_stepped_thread This PR shows that GDB can easily trigger an assertion here, in infrun.c: 5392 /* Did we find the stepping thread? */ 5393 if (tp->control.step_range_end) 5394 { 5395 /* Yep. There should only one though. */ 5396 gdb_assert (stepping_thread == NULL); 5397 5398 /* The event thread is handled at the top, before we 5399 enter this loop. */ 5400 gdb_assert (tp != ecs->event_thread); 5401 5402 /* If some thread other than the event thread is 5403 stepping, then scheduler locking can't be in effect, 5404 otherwise we wouldn't have resumed the current event 5405 thread in the first place. */ 5406 gdb_assert (!schedlock_applies (currently_stepping (tp))); 5407 5408 stepping_thread = tp; 5409 } Like: gdb/infrun.c:5406: internal-error: switch_back_to_stepped_thread: Assertion `!schedlock_applies (1)' failed. The way the assertion is written is assuming that with schedlock=step we'll always leave threads other than the one with the stepping range locked, while that's not true with the "next" command. With schedlock "step", other threads still run unlocked when "next" detects a function call and steps over it. Whether that makes sense or not, still, it's documented that way in the manual. If another thread hits an event that doesn't cause a stop while the nexting thread steps over a function call, we'll get here and fail the assertion. The fix is just to adjust the assertion. Even though we found the stepping thread, we'll still step-over the breakpoint that just triggered correctly. Surprisingly, gdb.threads/schedlock.exp doesn't have any test that steps over a function call. This commits fixes that. This ensures that "next" doesn't switch focus to another thread, and checks whether other threads run locked or not, depending on scheduler locking mode and command. There's a lot of duplication in that file that this ends cleaning up. There's more that could be cleaned up, but that would end up an unrelated change, best done separately. This new coverage in schedlock.exp happens to trigger the internal error in question, like so: FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (1) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (3) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (5) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (7) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (9) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next does not change thread (switched to thread 0) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: current thread advanced - unlocked (wrong amount) That's because we have more than one thread running the same loop, and while one thread is stepping over a function call, the other thread hits the step-resume breakpoint of the first, which needs to be stepped over, and we end up in switch_back_to_stepped_thread exactly in the problem case. I think a simpler and more directed test is also useful, to not rely on internal breakpoint magics. So this commit also adds a test that has a thread trip on a conditional breakpoint that doesn't cause a user-visible stop while another thread is stepping over a call. That currently fails like this: FAIL: gdb.threads/next-bp-other-thread.exp: schedlock=step: next over function call (GDB internal error) Tested on x86_64 Fedora 20. gdb/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * infrun.c (switch_back_to_stepped_thread): Use currently_stepping instead of assuming a thread with a stepping range is always stepping. gdb/testsuite/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * gdb.threads/schedlock.c (some_function): New function. (call_function): New global. (MAYBE_CALL_SOME_FUNCTION): New macro. (thread_function): Call it. * gdb.threads/schedlock.exp (get_args): Add description parameter, and use it instead of a global counter. Adjust all callers. (get_current_thread): Use "find current thread" for test message here rather than having all callers pass down the same string. (goto_loop): New procedure, factored out from ... (my_continue): ... this. (step_ten_loops): Change parameter from test message to command to use. Adjust. (list_count): Delete global. (check_result): New procedure, factored out from duplicate top level code. (continue tests): Wrap in with_test_prefix. (test_step): New procedure, factored out from duplicate top level code. (top level): Test "step" in combination with all scheduler-locking modes. Test "next" in combination with all scheduler-locking modes, and in combination with stepping over a function call or not. * gdb.threads/next-bp-other-thread.c: New file. * gdb.threads/next-bp-other-thread.exp: New file.
2014-10-29 19:15:39 +01:00
set test "current thread advanced"
if { $locked } {
set test "$test - locked"
} else {
set test "$test - unlocked"
}
PR 17408 - assertion failure in switch_back_to_stepped_thread This PR shows that GDB can easily trigger an assertion here, in infrun.c: 5392 /* Did we find the stepping thread? */ 5393 if (tp->control.step_range_end) 5394 { 5395 /* Yep. There should only one though. */ 5396 gdb_assert (stepping_thread == NULL); 5397 5398 /* The event thread is handled at the top, before we 5399 enter this loop. */ 5400 gdb_assert (tp != ecs->event_thread); 5401 5402 /* If some thread other than the event thread is 5403 stepping, then scheduler locking can't be in effect, 5404 otherwise we wouldn't have resumed the current event 5405 thread in the first place. */ 5406 gdb_assert (!schedlock_applies (currently_stepping (tp))); 5407 5408 stepping_thread = tp; 5409 } Like: gdb/infrun.c:5406: internal-error: switch_back_to_stepped_thread: Assertion `!schedlock_applies (1)' failed. The way the assertion is written is assuming that with schedlock=step we'll always leave threads other than the one with the stepping range locked, while that's not true with the "next" command. With schedlock "step", other threads still run unlocked when "next" detects a function call and steps over it. Whether that makes sense or not, still, it's documented that way in the manual. If another thread hits an event that doesn't cause a stop while the nexting thread steps over a function call, we'll get here and fail the assertion. The fix is just to adjust the assertion. Even though we found the stepping thread, we'll still step-over the breakpoint that just triggered correctly. Surprisingly, gdb.threads/schedlock.exp doesn't have any test that steps over a function call. This commits fixes that. This ensures that "next" doesn't switch focus to another thread, and checks whether other threads run locked or not, depending on scheduler locking mode and command. There's a lot of duplication in that file that this ends cleaning up. There's more that could be cleaned up, but that would end up an unrelated change, best done separately. This new coverage in schedlock.exp happens to trigger the internal error in question, like so: FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (1) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (3) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (5) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (7) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (9) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next does not change thread (switched to thread 0) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: current thread advanced - unlocked (wrong amount) That's because we have more than one thread running the same loop, and while one thread is stepping over a function call, the other thread hits the step-resume breakpoint of the first, which needs to be stepped over, and we end up in switch_back_to_stepped_thread exactly in the problem case. I think a simpler and more directed test is also useful, to not rely on internal breakpoint magics. So this commit also adds a test that has a thread trip on a conditional breakpoint that doesn't cause a user-visible stop while another thread is stepping over a call. That currently fails like this: FAIL: gdb.threads/next-bp-other-thread.exp: schedlock=step: next over function call (GDB internal error) Tested on x86_64 Fedora 20. gdb/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * infrun.c (switch_back_to_stepped_thread): Use currently_stepping instead of assuming a thread with a stepping range is always stepping. gdb/testsuite/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * gdb.threads/schedlock.c (some_function): New function. (call_function): New global. (MAYBE_CALL_SOME_FUNCTION): New macro. (thread_function): Call it. * gdb.threads/schedlock.exp (get_args): Add description parameter, and use it instead of a global counter. Adjust all callers. (get_current_thread): Use "find current thread" for test message here rather than having all callers pass down the same string. (goto_loop): New procedure, factored out from ... (my_continue): ... this. (step_ten_loops): Change parameter from test message to command to use. Adjust. (list_count): Delete global. (check_result): New procedure, factored out from duplicate top level code. (continue tests): Wrap in with_test_prefix. (test_step): New procedure, factored out from duplicate top level code. (top level): Test "step" in combination with all scheduler-locking modes. Test "next" in combination with all scheduler-locking modes, and in combination with stepping over a function call or not. * gdb.threads/next-bp-other-thread.c: New file. * gdb.threads/next-bp-other-thread.exp: New file.
2014-10-29 19:15:39 +01:00
set num_other_threads 0
for {set i 0} {$i < $NUM} {incr i} {
if {[lindex $before_args $i] == [lindex $after_args $i]} {
if {$i == $before_thread} {
fail "$test (didn't run)"
}
} else {
PR 17408 - assertion failure in switch_back_to_stepped_thread This PR shows that GDB can easily trigger an assertion here, in infrun.c: 5392 /* Did we find the stepping thread? */ 5393 if (tp->control.step_range_end) 5394 { 5395 /* Yep. There should only one though. */ 5396 gdb_assert (stepping_thread == NULL); 5397 5398 /* The event thread is handled at the top, before we 5399 enter this loop. */ 5400 gdb_assert (tp != ecs->event_thread); 5401 5402 /* If some thread other than the event thread is 5403 stepping, then scheduler locking can't be in effect, 5404 otherwise we wouldn't have resumed the current event 5405 thread in the first place. */ 5406 gdb_assert (!schedlock_applies (currently_stepping (tp))); 5407 5408 stepping_thread = tp; 5409 } Like: gdb/infrun.c:5406: internal-error: switch_back_to_stepped_thread: Assertion `!schedlock_applies (1)' failed. The way the assertion is written is assuming that with schedlock=step we'll always leave threads other than the one with the stepping range locked, while that's not true with the "next" command. With schedlock "step", other threads still run unlocked when "next" detects a function call and steps over it. Whether that makes sense or not, still, it's documented that way in the manual. If another thread hits an event that doesn't cause a stop while the nexting thread steps over a function call, we'll get here and fail the assertion. The fix is just to adjust the assertion. Even though we found the stepping thread, we'll still step-over the breakpoint that just triggered correctly. Surprisingly, gdb.threads/schedlock.exp doesn't have any test that steps over a function call. This commits fixes that. This ensures that "next" doesn't switch focus to another thread, and checks whether other threads run locked or not, depending on scheduler locking mode and command. There's a lot of duplication in that file that this ends cleaning up. There's more that could be cleaned up, but that would end up an unrelated change, best done separately. This new coverage in schedlock.exp happens to trigger the internal error in question, like so: FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (1) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (3) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (5) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (7) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (9) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next does not change thread (switched to thread 0) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: current thread advanced - unlocked (wrong amount) That's because we have more than one thread running the same loop, and while one thread is stepping over a function call, the other thread hits the step-resume breakpoint of the first, which needs to be stepped over, and we end up in switch_back_to_stepped_thread exactly in the problem case. I think a simpler and more directed test is also useful, to not rely on internal breakpoint magics. So this commit also adds a test that has a thread trip on a conditional breakpoint that doesn't cause a user-visible stop while another thread is stepping over a call. That currently fails like this: FAIL: gdb.threads/next-bp-other-thread.exp: schedlock=step: next over function call (GDB internal error) Tested on x86_64 Fedora 20. gdb/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * infrun.c (switch_back_to_stepped_thread): Use currently_stepping instead of assuming a thread with a stepping range is always stepping. gdb/testsuite/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * gdb.threads/schedlock.c (some_function): New function. (call_function): New global. (MAYBE_CALL_SOME_FUNCTION): New macro. (thread_function): Call it. * gdb.threads/schedlock.exp (get_args): Add description parameter, and use it instead of a global counter. Adjust all callers. (get_current_thread): Use "find current thread" for test message here rather than having all callers pass down the same string. (goto_loop): New procedure, factored out from ... (my_continue): ... this. (step_ten_loops): Change parameter from test message to command to use. Adjust. (list_count): Delete global. (check_result): New procedure, factored out from duplicate top level code. (continue tests): Wrap in with_test_prefix. (test_step): New procedure, factored out from duplicate top level code. (top level): Test "step" in combination with all scheduler-locking modes. Test "next" in combination with all scheduler-locking modes, and in combination with stepping over a function call or not. * gdb.threads/next-bp-other-thread.c: New file. * gdb.threads/next-bp-other-thread.exp: New file.
2014-10-29 19:15:39 +01:00
if {$i == $before_thread} {
if {$cmd == "continue"
|| [lindex $before_args $i] == [expr [lindex $after_args $i] - 10]} {
pass "$test"
} else {
fail "$test (wrong amount)"
}
} else {
incr num_other_threads
}
}
PR 17408 - assertion failure in switch_back_to_stepped_thread This PR shows that GDB can easily trigger an assertion here, in infrun.c: 5392 /* Did we find the stepping thread? */ 5393 if (tp->control.step_range_end) 5394 { 5395 /* Yep. There should only one though. */ 5396 gdb_assert (stepping_thread == NULL); 5397 5398 /* The event thread is handled at the top, before we 5399 enter this loop. */ 5400 gdb_assert (tp != ecs->event_thread); 5401 5402 /* If some thread other than the event thread is 5403 stepping, then scheduler locking can't be in effect, 5404 otherwise we wouldn't have resumed the current event 5405 thread in the first place. */ 5406 gdb_assert (!schedlock_applies (currently_stepping (tp))); 5407 5408 stepping_thread = tp; 5409 } Like: gdb/infrun.c:5406: internal-error: switch_back_to_stepped_thread: Assertion `!schedlock_applies (1)' failed. The way the assertion is written is assuming that with schedlock=step we'll always leave threads other than the one with the stepping range locked, while that's not true with the "next" command. With schedlock "step", other threads still run unlocked when "next" detects a function call and steps over it. Whether that makes sense or not, still, it's documented that way in the manual. If another thread hits an event that doesn't cause a stop while the nexting thread steps over a function call, we'll get here and fail the assertion. The fix is just to adjust the assertion. Even though we found the stepping thread, we'll still step-over the breakpoint that just triggered correctly. Surprisingly, gdb.threads/schedlock.exp doesn't have any test that steps over a function call. This commits fixes that. This ensures that "next" doesn't switch focus to another thread, and checks whether other threads run locked or not, depending on scheduler locking mode and command. There's a lot of duplication in that file that this ends cleaning up. There's more that could be cleaned up, but that would end up an unrelated change, best done separately. This new coverage in schedlock.exp happens to trigger the internal error in question, like so: FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (1) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (3) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (5) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (7) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (9) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next does not change thread (switched to thread 0) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: current thread advanced - unlocked (wrong amount) That's because we have more than one thread running the same loop, and while one thread is stepping over a function call, the other thread hits the step-resume breakpoint of the first, which needs to be stepped over, and we end up in switch_back_to_stepped_thread exactly in the problem case. I think a simpler and more directed test is also useful, to not rely on internal breakpoint magics. So this commit also adds a test that has a thread trip on a conditional breakpoint that doesn't cause a user-visible stop while another thread is stepping over a call. That currently fails like this: FAIL: gdb.threads/next-bp-other-thread.exp: schedlock=step: next over function call (GDB internal error) Tested on x86_64 Fedora 20. gdb/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * infrun.c (switch_back_to_stepped_thread): Use currently_stepping instead of assuming a thread with a stepping range is always stepping. gdb/testsuite/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * gdb.threads/schedlock.c (some_function): New function. (call_function): New global. (MAYBE_CALL_SOME_FUNCTION): New macro. (thread_function): Call it. * gdb.threads/schedlock.exp (get_args): Add description parameter, and use it instead of a global counter. Adjust all callers. (get_current_thread): Use "find current thread" for test message here rather than having all callers pass down the same string. (goto_loop): New procedure, factored out from ... (my_continue): ... this. (step_ten_loops): Change parameter from test message to command to use. Adjust. (list_count): Delete global. (check_result): New procedure, factored out from duplicate top level code. (continue tests): Wrap in with_test_prefix. (test_step): New procedure, factored out from duplicate top level code. (top level): Test "step" in combination with all scheduler-locking modes. Test "next" in combination with all scheduler-locking modes, and in combination with stepping over a function call or not. * gdb.threads/next-bp-other-thread.c: New file. * gdb.threads/next-bp-other-thread.exp: New file.
2014-10-29 19:15:39 +01:00
}
if { $locked } {
gdb_assert {$num_other_threads == 0} "other threads didn't run - locked"
} else {
PR 17408 - assertion failure in switch_back_to_stepped_thread This PR shows that GDB can easily trigger an assertion here, in infrun.c: 5392 /* Did we find the stepping thread? */ 5393 if (tp->control.step_range_end) 5394 { 5395 /* Yep. There should only one though. */ 5396 gdb_assert (stepping_thread == NULL); 5397 5398 /* The event thread is handled at the top, before we 5399 enter this loop. */ 5400 gdb_assert (tp != ecs->event_thread); 5401 5402 /* If some thread other than the event thread is 5403 stepping, then scheduler locking can't be in effect, 5404 otherwise we wouldn't have resumed the current event 5405 thread in the first place. */ 5406 gdb_assert (!schedlock_applies (currently_stepping (tp))); 5407 5408 stepping_thread = tp; 5409 } Like: gdb/infrun.c:5406: internal-error: switch_back_to_stepped_thread: Assertion `!schedlock_applies (1)' failed. The way the assertion is written is assuming that with schedlock=step we'll always leave threads other than the one with the stepping range locked, while that's not true with the "next" command. With schedlock "step", other threads still run unlocked when "next" detects a function call and steps over it. Whether that makes sense or not, still, it's documented that way in the manual. If another thread hits an event that doesn't cause a stop while the nexting thread steps over a function call, we'll get here and fail the assertion. The fix is just to adjust the assertion. Even though we found the stepping thread, we'll still step-over the breakpoint that just triggered correctly. Surprisingly, gdb.threads/schedlock.exp doesn't have any test that steps over a function call. This commits fixes that. This ensures that "next" doesn't switch focus to another thread, and checks whether other threads run locked or not, depending on scheduler locking mode and command. There's a lot of duplication in that file that this ends cleaning up. There's more that could be cleaned up, but that would end up an unrelated change, best done separately. This new coverage in schedlock.exp happens to trigger the internal error in question, like so: FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (1) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (3) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (5) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (7) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (9) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next does not change thread (switched to thread 0) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: current thread advanced - unlocked (wrong amount) That's because we have more than one thread running the same loop, and while one thread is stepping over a function call, the other thread hits the step-resume breakpoint of the first, which needs to be stepped over, and we end up in switch_back_to_stepped_thread exactly in the problem case. I think a simpler and more directed test is also useful, to not rely on internal breakpoint magics. So this commit also adds a test that has a thread trip on a conditional breakpoint that doesn't cause a user-visible stop while another thread is stepping over a call. That currently fails like this: FAIL: gdb.threads/next-bp-other-thread.exp: schedlock=step: next over function call (GDB internal error) Tested on x86_64 Fedora 20. gdb/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * infrun.c (switch_back_to_stepped_thread): Use currently_stepping instead of assuming a thread with a stepping range is always stepping. gdb/testsuite/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * gdb.threads/schedlock.c (some_function): New function. (call_function): New global. (MAYBE_CALL_SOME_FUNCTION): New macro. (thread_function): Call it. * gdb.threads/schedlock.exp (get_args): Add description parameter, and use it instead of a global counter. Adjust all callers. (get_current_thread): Use "find current thread" for test message here rather than having all callers pass down the same string. (goto_loop): New procedure, factored out from ... (my_continue): ... this. (step_ten_loops): Change parameter from test message to command to use. Adjust. (list_count): Delete global. (check_result): New procedure, factored out from duplicate top level code. (continue tests): Wrap in with_test_prefix. (test_step): New procedure, factored out from duplicate top level code. (top level): Test "step" in combination with all scheduler-locking modes. Test "next" in combination with all scheduler-locking modes, and in combination with stepping over a function call or not. * gdb.threads/next-bp-other-thread.c: New file. * gdb.threads/next-bp-other-thread.exp: New file.
2014-10-29 19:15:39 +01:00
gdb_assert {$num_other_threads > 0} "other threads ran - unlocked"
}
}
PR 17408 - assertion failure in switch_back_to_stepped_thread This PR shows that GDB can easily trigger an assertion here, in infrun.c: 5392 /* Did we find the stepping thread? */ 5393 if (tp->control.step_range_end) 5394 { 5395 /* Yep. There should only one though. */ 5396 gdb_assert (stepping_thread == NULL); 5397 5398 /* The event thread is handled at the top, before we 5399 enter this loop. */ 5400 gdb_assert (tp != ecs->event_thread); 5401 5402 /* If some thread other than the event thread is 5403 stepping, then scheduler locking can't be in effect, 5404 otherwise we wouldn't have resumed the current event 5405 thread in the first place. */ 5406 gdb_assert (!schedlock_applies (currently_stepping (tp))); 5407 5408 stepping_thread = tp; 5409 } Like: gdb/infrun.c:5406: internal-error: switch_back_to_stepped_thread: Assertion `!schedlock_applies (1)' failed. The way the assertion is written is assuming that with schedlock=step we'll always leave threads other than the one with the stepping range locked, while that's not true with the "next" command. With schedlock "step", other threads still run unlocked when "next" detects a function call and steps over it. Whether that makes sense or not, still, it's documented that way in the manual. If another thread hits an event that doesn't cause a stop while the nexting thread steps over a function call, we'll get here and fail the assertion. The fix is just to adjust the assertion. Even though we found the stepping thread, we'll still step-over the breakpoint that just triggered correctly. Surprisingly, gdb.threads/schedlock.exp doesn't have any test that steps over a function call. This commits fixes that. This ensures that "next" doesn't switch focus to another thread, and checks whether other threads run locked or not, depending on scheduler locking mode and command. There's a lot of duplication in that file that this ends cleaning up. There's more that could be cleaned up, but that would end up an unrelated change, best done separately. This new coverage in schedlock.exp happens to trigger the internal error in question, like so: FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (1) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (3) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (5) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (7) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (9) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next does not change thread (switched to thread 0) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: current thread advanced - unlocked (wrong amount) That's because we have more than one thread running the same loop, and while one thread is stepping over a function call, the other thread hits the step-resume breakpoint of the first, which needs to be stepped over, and we end up in switch_back_to_stepped_thread exactly in the problem case. I think a simpler and more directed test is also useful, to not rely on internal breakpoint magics. So this commit also adds a test that has a thread trip on a conditional breakpoint that doesn't cause a user-visible stop while another thread is stepping over a call. That currently fails like this: FAIL: gdb.threads/next-bp-other-thread.exp: schedlock=step: next over function call (GDB internal error) Tested on x86_64 Fedora 20. gdb/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * infrun.c (switch_back_to_stepped_thread): Use currently_stepping instead of assuming a thread with a stepping range is always stepping. gdb/testsuite/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * gdb.threads/schedlock.c (some_function): New function. (call_function): New global. (MAYBE_CALL_SOME_FUNCTION): New macro. (thread_function): Call it. * gdb.threads/schedlock.exp (get_args): Add description parameter, and use it instead of a global counter. Adjust all callers. (get_current_thread): Use "find current thread" for test message here rather than having all callers pass down the same string. (goto_loop): New procedure, factored out from ... (my_continue): ... this. (step_ten_loops): Change parameter from test message to command to use. Adjust. (list_count): Delete global. (check_result): New procedure, factored out from duplicate top level code. (continue tests): Wrap in with_test_prefix. (test_step): New procedure, factored out from duplicate top level code. (top level): Test "step" in combination with all scheduler-locking modes. Test "next" in combination with all scheduler-locking modes, and in combination with stepping over a function call or not. * gdb.threads/next-bp-other-thread.c: New file. * gdb.threads/next-bp-other-thread.exp: New file.
2014-10-29 19:15:39 +01:00
with_test_prefix "schedlock=on: cmd=continue" {
# Use whichever we stopped in.
set curthread [get_current_thread "before"]
PR 17408 - assertion failure in switch_back_to_stepped_thread This PR shows that GDB can easily trigger an assertion here, in infrun.c: 5392 /* Did we find the stepping thread? */ 5393 if (tp->control.step_range_end) 5394 { 5395 /* Yep. There should only one though. */ 5396 gdb_assert (stepping_thread == NULL); 5397 5398 /* The event thread is handled at the top, before we 5399 enter this loop. */ 5400 gdb_assert (tp != ecs->event_thread); 5401 5402 /* If some thread other than the event thread is 5403 stepping, then scheduler locking can't be in effect, 5404 otherwise we wouldn't have resumed the current event 5405 thread in the first place. */ 5406 gdb_assert (!schedlock_applies (currently_stepping (tp))); 5407 5408 stepping_thread = tp; 5409 } Like: gdb/infrun.c:5406: internal-error: switch_back_to_stepped_thread: Assertion `!schedlock_applies (1)' failed. The way the assertion is written is assuming that with schedlock=step we'll always leave threads other than the one with the stepping range locked, while that's not true with the "next" command. With schedlock "step", other threads still run unlocked when "next" detects a function call and steps over it. Whether that makes sense or not, still, it's documented that way in the manual. If another thread hits an event that doesn't cause a stop while the nexting thread steps over a function call, we'll get here and fail the assertion. The fix is just to adjust the assertion. Even though we found the stepping thread, we'll still step-over the breakpoint that just triggered correctly. Surprisingly, gdb.threads/schedlock.exp doesn't have any test that steps over a function call. This commits fixes that. This ensures that "next" doesn't switch focus to another thread, and checks whether other threads run locked or not, depending on scheduler locking mode and command. There's a lot of duplication in that file that this ends cleaning up. There's more that could be cleaned up, but that would end up an unrelated change, best done separately. This new coverage in schedlock.exp happens to trigger the internal error in question, like so: FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (1) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (3) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (5) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (7) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (9) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next does not change thread (switched to thread 0) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: current thread advanced - unlocked (wrong amount) That's because we have more than one thread running the same loop, and while one thread is stepping over a function call, the other thread hits the step-resume breakpoint of the first, which needs to be stepped over, and we end up in switch_back_to_stepped_thread exactly in the problem case. I think a simpler and more directed test is also useful, to not rely on internal breakpoint magics. So this commit also adds a test that has a thread trip on a conditional breakpoint that doesn't cause a user-visible stop while another thread is stepping over a call. That currently fails like this: FAIL: gdb.threads/next-bp-other-thread.exp: schedlock=step: next over function call (GDB internal error) Tested on x86_64 Fedora 20. gdb/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * infrun.c (switch_back_to_stepped_thread): Use currently_stepping instead of assuming a thread with a stepping range is always stepping. gdb/testsuite/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * gdb.threads/schedlock.c (some_function): New function. (call_function): New global. (MAYBE_CALL_SOME_FUNCTION): New macro. (thread_function): Call it. * gdb.threads/schedlock.exp (get_args): Add description parameter, and use it instead of a global counter. Adjust all callers. (get_current_thread): Use "find current thread" for test message here rather than having all callers pass down the same string. (goto_loop): New procedure, factored out from ... (my_continue): ... this. (step_ten_loops): Change parameter from test message to command to use. Adjust. (list_count): Delete global. (check_result): New procedure, factored out from duplicate top level code. (continue tests): Wrap in with_test_prefix. (test_step): New procedure, factored out from duplicate top level code. (top level): Test "step" in combination with all scheduler-locking modes. Test "next" in combination with all scheduler-locking modes, and in combination with stepping over a function call or not. * gdb.threads/next-bp-other-thread.c: New file. * gdb.threads/next-bp-other-thread.exp: New file.
2014-10-29 19:15:39 +01:00
# Test continue with scheduler locking.
gdb_test "set scheduler-locking on" ""
PR 17408 - assertion failure in switch_back_to_stepped_thread This PR shows that GDB can easily trigger an assertion here, in infrun.c: 5392 /* Did we find the stepping thread? */ 5393 if (tp->control.step_range_end) 5394 { 5395 /* Yep. There should only one though. */ 5396 gdb_assert (stepping_thread == NULL); 5397 5398 /* The event thread is handled at the top, before we 5399 enter this loop. */ 5400 gdb_assert (tp != ecs->event_thread); 5401 5402 /* If some thread other than the event thread is 5403 stepping, then scheduler locking can't be in effect, 5404 otherwise we wouldn't have resumed the current event 5405 thread in the first place. */ 5406 gdb_assert (!schedlock_applies (currently_stepping (tp))); 5407 5408 stepping_thread = tp; 5409 } Like: gdb/infrun.c:5406: internal-error: switch_back_to_stepped_thread: Assertion `!schedlock_applies (1)' failed. The way the assertion is written is assuming that with schedlock=step we'll always leave threads other than the one with the stepping range locked, while that's not true with the "next" command. With schedlock "step", other threads still run unlocked when "next" detects a function call and steps over it. Whether that makes sense or not, still, it's documented that way in the manual. If another thread hits an event that doesn't cause a stop while the nexting thread steps over a function call, we'll get here and fail the assertion. The fix is just to adjust the assertion. Even though we found the stepping thread, we'll still step-over the breakpoint that just triggered correctly. Surprisingly, gdb.threads/schedlock.exp doesn't have any test that steps over a function call. This commits fixes that. This ensures that "next" doesn't switch focus to another thread, and checks whether other threads run locked or not, depending on scheduler locking mode and command. There's a lot of duplication in that file that this ends cleaning up. There's more that could be cleaned up, but that would end up an unrelated change, best done separately. This new coverage in schedlock.exp happens to trigger the internal error in question, like so: FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (1) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (3) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (5) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (7) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (9) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next does not change thread (switched to thread 0) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: current thread advanced - unlocked (wrong amount) That's because we have more than one thread running the same loop, and while one thread is stepping over a function call, the other thread hits the step-resume breakpoint of the first, which needs to be stepped over, and we end up in switch_back_to_stepped_thread exactly in the problem case. I think a simpler and more directed test is also useful, to not rely on internal breakpoint magics. So this commit also adds a test that has a thread trip on a conditional breakpoint that doesn't cause a user-visible stop while another thread is stepping over a call. That currently fails like this: FAIL: gdb.threads/next-bp-other-thread.exp: schedlock=step: next over function call (GDB internal error) Tested on x86_64 Fedora 20. gdb/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * infrun.c (switch_back_to_stepped_thread): Use currently_stepping instead of assuming a thread with a stepping range is always stepping. gdb/testsuite/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * gdb.threads/schedlock.c (some_function): New function. (call_function): New global. (MAYBE_CALL_SOME_FUNCTION): New macro. (thread_function): Call it. * gdb.threads/schedlock.exp (get_args): Add description parameter, and use it instead of a global counter. Adjust all callers. (get_current_thread): Use "find current thread" for test message here rather than having all callers pass down the same string. (goto_loop): New procedure, factored out from ... (my_continue): ... this. (step_ten_loops): Change parameter from test message to command to use. Adjust. (list_count): Delete global. (check_result): New procedure, factored out from duplicate top level code. (continue tests): Wrap in with_test_prefix. (test_step): New procedure, factored out from duplicate top level code. (top level): Test "step" in combination with all scheduler-locking modes. Test "next" in combination with all scheduler-locking modes, and in combination with stepping over a function call or not. * gdb.threads/next-bp-other-thread.c: New file. * gdb.threads/next-bp-other-thread.exp: New file.
2014-10-29 19:15:39 +01:00
my_continue "with lock"
check_result "continue" $curthread $cont_args 1
}
PR 17408 - assertion failure in switch_back_to_stepped_thread This PR shows that GDB can easily trigger an assertion here, in infrun.c: 5392 /* Did we find the stepping thread? */ 5393 if (tp->control.step_range_end) 5394 { 5395 /* Yep. There should only one though. */ 5396 gdb_assert (stepping_thread == NULL); 5397 5398 /* The event thread is handled at the top, before we 5399 enter this loop. */ 5400 gdb_assert (tp != ecs->event_thread); 5401 5402 /* If some thread other than the event thread is 5403 stepping, then scheduler locking can't be in effect, 5404 otherwise we wouldn't have resumed the current event 5405 thread in the first place. */ 5406 gdb_assert (!schedlock_applies (currently_stepping (tp))); 5407 5408 stepping_thread = tp; 5409 } Like: gdb/infrun.c:5406: internal-error: switch_back_to_stepped_thread: Assertion `!schedlock_applies (1)' failed. The way the assertion is written is assuming that with schedlock=step we'll always leave threads other than the one with the stepping range locked, while that's not true with the "next" command. With schedlock "step", other threads still run unlocked when "next" detects a function call and steps over it. Whether that makes sense or not, still, it's documented that way in the manual. If another thread hits an event that doesn't cause a stop while the nexting thread steps over a function call, we'll get here and fail the assertion. The fix is just to adjust the assertion. Even though we found the stepping thread, we'll still step-over the breakpoint that just triggered correctly. Surprisingly, gdb.threads/schedlock.exp doesn't have any test that steps over a function call. This commits fixes that. This ensures that "next" doesn't switch focus to another thread, and checks whether other threads run locked or not, depending on scheduler locking mode and command. There's a lot of duplication in that file that this ends cleaning up. There's more that could be cleaned up, but that would end up an unrelated change, best done separately. This new coverage in schedlock.exp happens to trigger the internal error in question, like so: FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (1) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (3) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (5) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (7) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (9) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next does not change thread (switched to thread 0) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: current thread advanced - unlocked (wrong amount) That's because we have more than one thread running the same loop, and while one thread is stepping over a function call, the other thread hits the step-resume breakpoint of the first, which needs to be stepped over, and we end up in switch_back_to_stepped_thread exactly in the problem case. I think a simpler and more directed test is also useful, to not rely on internal breakpoint magics. So this commit also adds a test that has a thread trip on a conditional breakpoint that doesn't cause a user-visible stop while another thread is stepping over a call. That currently fails like this: FAIL: gdb.threads/next-bp-other-thread.exp: schedlock=step: next over function call (GDB internal error) Tested on x86_64 Fedora 20. gdb/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * infrun.c (switch_back_to_stepped_thread): Use currently_stepping instead of assuming a thread with a stepping range is always stepping. gdb/testsuite/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * gdb.threads/schedlock.c (some_function): New function. (call_function): New global. (MAYBE_CALL_SOME_FUNCTION): New macro. (thread_function): Call it. * gdb.threads/schedlock.exp (get_args): Add description parameter, and use it instead of a global counter. Adjust all callers. (get_current_thread): Use "find current thread" for test message here rather than having all callers pass down the same string. (goto_loop): New procedure, factored out from ... (my_continue): ... this. (step_ten_loops): Change parameter from test message to command to use. Adjust. (list_count): Delete global. (check_result): New procedure, factored out from duplicate top level code. (continue tests): Wrap in with_test_prefix. (test_step): New procedure, factored out from duplicate top level code. (top level): Test "step" in combination with all scheduler-locking modes. Test "next" in combination with all scheduler-locking modes, and in combination with stepping over a function call or not. * gdb.threads/next-bp-other-thread.c: New file. * gdb.threads/next-bp-other-thread.exp: New file.
2014-10-29 19:15:39 +01:00
# Test stepping/nexting with different modes of scheduler locking.
proc test_step { schedlock cmd call_function } {
global NUM
PR 17408 - assertion failure in switch_back_to_stepped_thread This PR shows that GDB can easily trigger an assertion here, in infrun.c: 5392 /* Did we find the stepping thread? */ 5393 if (tp->control.step_range_end) 5394 { 5395 /* Yep. There should only one though. */ 5396 gdb_assert (stepping_thread == NULL); 5397 5398 /* The event thread is handled at the top, before we 5399 enter this loop. */ 5400 gdb_assert (tp != ecs->event_thread); 5401 5402 /* If some thread other than the event thread is 5403 stepping, then scheduler locking can't be in effect, 5404 otherwise we wouldn't have resumed the current event 5405 thread in the first place. */ 5406 gdb_assert (!schedlock_applies (currently_stepping (tp))); 5407 5408 stepping_thread = tp; 5409 } Like: gdb/infrun.c:5406: internal-error: switch_back_to_stepped_thread: Assertion `!schedlock_applies (1)' failed. The way the assertion is written is assuming that with schedlock=step we'll always leave threads other than the one with the stepping range locked, while that's not true with the "next" command. With schedlock "step", other threads still run unlocked when "next" detects a function call and steps over it. Whether that makes sense or not, still, it's documented that way in the manual. If another thread hits an event that doesn't cause a stop while the nexting thread steps over a function call, we'll get here and fail the assertion. The fix is just to adjust the assertion. Even though we found the stepping thread, we'll still step-over the breakpoint that just triggered correctly. Surprisingly, gdb.threads/schedlock.exp doesn't have any test that steps over a function call. This commits fixes that. This ensures that "next" doesn't switch focus to another thread, and checks whether other threads run locked or not, depending on scheduler locking mode and command. There's a lot of duplication in that file that this ends cleaning up. There's more that could be cleaned up, but that would end up an unrelated change, best done separately. This new coverage in schedlock.exp happens to trigger the internal error in question, like so: FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (1) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (3) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (5) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (7) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (9) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next does not change thread (switched to thread 0) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: current thread advanced - unlocked (wrong amount) That's because we have more than one thread running the same loop, and while one thread is stepping over a function call, the other thread hits the step-resume breakpoint of the first, which needs to be stepped over, and we end up in switch_back_to_stepped_thread exactly in the problem case. I think a simpler and more directed test is also useful, to not rely on internal breakpoint magics. So this commit also adds a test that has a thread trip on a conditional breakpoint that doesn't cause a user-visible stop while another thread is stepping over a call. That currently fails like this: FAIL: gdb.threads/next-bp-other-thread.exp: schedlock=step: next over function call (GDB internal error) Tested on x86_64 Fedora 20. gdb/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * infrun.c (switch_back_to_stepped_thread): Use currently_stepping instead of assuming a thread with a stepping range is always stepping. gdb/testsuite/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * gdb.threads/schedlock.c (some_function): New function. (call_function): New global. (MAYBE_CALL_SOME_FUNCTION): New macro. (thread_function): Call it. * gdb.threads/schedlock.exp (get_args): Add description parameter, and use it instead of a global counter. Adjust all callers. (get_current_thread): Use "find current thread" for test message here rather than having all callers pass down the same string. (goto_loop): New procedure, factored out from ... (my_continue): ... this. (step_ten_loops): Change parameter from test message to command to use. Adjust. (list_count): Delete global. (check_result): New procedure, factored out from duplicate top level code. (continue tests): Wrap in with_test_prefix. (test_step): New procedure, factored out from duplicate top level code. (top level): Test "step" in combination with all scheduler-locking modes. Test "next" in combination with all scheduler-locking modes, and in combination with stepping over a function call or not. * gdb.threads/next-bp-other-thread.c: New file. * gdb.threads/next-bp-other-thread.exp: New file.
2014-10-29 19:15:39 +01:00
gdb_test_no_output "set scheduler-locking off"
goto_loop ""
set curthread [get_current_thread "before"]
# No need to set to off again. This avoids a duplicate message.
if {$schedlock != "off"} {
gdb_test_no_output "set scheduler-locking $schedlock"
}
PR 17408 - assertion failure in switch_back_to_stepped_thread This PR shows that GDB can easily trigger an assertion here, in infrun.c: 5392 /* Did we find the stepping thread? */ 5393 if (tp->control.step_range_end) 5394 { 5395 /* Yep. There should only one though. */ 5396 gdb_assert (stepping_thread == NULL); 5397 5398 /* The event thread is handled at the top, before we 5399 enter this loop. */ 5400 gdb_assert (tp != ecs->event_thread); 5401 5402 /* If some thread other than the event thread is 5403 stepping, then scheduler locking can't be in effect, 5404 otherwise we wouldn't have resumed the current event 5405 thread in the first place. */ 5406 gdb_assert (!schedlock_applies (currently_stepping (tp))); 5407 5408 stepping_thread = tp; 5409 } Like: gdb/infrun.c:5406: internal-error: switch_back_to_stepped_thread: Assertion `!schedlock_applies (1)' failed. The way the assertion is written is assuming that with schedlock=step we'll always leave threads other than the one with the stepping range locked, while that's not true with the "next" command. With schedlock "step", other threads still run unlocked when "next" detects a function call and steps over it. Whether that makes sense or not, still, it's documented that way in the manual. If another thread hits an event that doesn't cause a stop while the nexting thread steps over a function call, we'll get here and fail the assertion. The fix is just to adjust the assertion. Even though we found the stepping thread, we'll still step-over the breakpoint that just triggered correctly. Surprisingly, gdb.threads/schedlock.exp doesn't have any test that steps over a function call. This commits fixes that. This ensures that "next" doesn't switch focus to another thread, and checks whether other threads run locked or not, depending on scheduler locking mode and command. There's a lot of duplication in that file that this ends cleaning up. There's more that could be cleaned up, but that would end up an unrelated change, best done separately. This new coverage in schedlock.exp happens to trigger the internal error in question, like so: FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (1) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (3) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (5) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (7) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (9) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next does not change thread (switched to thread 0) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: current thread advanced - unlocked (wrong amount) That's because we have more than one thread running the same loop, and while one thread is stepping over a function call, the other thread hits the step-resume breakpoint of the first, which needs to be stepped over, and we end up in switch_back_to_stepped_thread exactly in the problem case. I think a simpler and more directed test is also useful, to not rely on internal breakpoint magics. So this commit also adds a test that has a thread trip on a conditional breakpoint that doesn't cause a user-visible stop while another thread is stepping over a call. That currently fails like this: FAIL: gdb.threads/next-bp-other-thread.exp: schedlock=step: next over function call (GDB internal error) Tested on x86_64 Fedora 20. gdb/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * infrun.c (switch_back_to_stepped_thread): Use currently_stepping instead of assuming a thread with a stepping range is always stepping. gdb/testsuite/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * gdb.threads/schedlock.c (some_function): New function. (call_function): New global. (MAYBE_CALL_SOME_FUNCTION): New macro. (thread_function): Call it. * gdb.threads/schedlock.exp (get_args): Add description parameter, and use it instead of a global counter. Adjust all callers. (get_current_thread): Use "find current thread" for test message here rather than having all callers pass down the same string. (goto_loop): New procedure, factored out from ... (my_continue): ... this. (step_ten_loops): Change parameter from test message to command to use. Adjust. (list_count): Delete global. (check_result): New procedure, factored out from duplicate top level code. (continue tests): Wrap in with_test_prefix. (test_step): New procedure, factored out from duplicate top level code. (top level): Test "step" in combination with all scheduler-locking modes. Test "next" in combination with all scheduler-locking modes, and in combination with stepping over a function call or not. * gdb.threads/next-bp-other-thread.c: New file. * gdb.threads/next-bp-other-thread.exp: New file.
2014-10-29 19:15:39 +01:00
gdb_test "print call_function = $call_function" \
" = $call_function"
PR 17408 - assertion failure in switch_back_to_stepped_thread This PR shows that GDB can easily trigger an assertion here, in infrun.c: 5392 /* Did we find the stepping thread? */ 5393 if (tp->control.step_range_end) 5394 { 5395 /* Yep. There should only one though. */ 5396 gdb_assert (stepping_thread == NULL); 5397 5398 /* The event thread is handled at the top, before we 5399 enter this loop. */ 5400 gdb_assert (tp != ecs->event_thread); 5401 5402 /* If some thread other than the event thread is 5403 stepping, then scheduler locking can't be in effect, 5404 otherwise we wouldn't have resumed the current event 5405 thread in the first place. */ 5406 gdb_assert (!schedlock_applies (currently_stepping (tp))); 5407 5408 stepping_thread = tp; 5409 } Like: gdb/infrun.c:5406: internal-error: switch_back_to_stepped_thread: Assertion `!schedlock_applies (1)' failed. The way the assertion is written is assuming that with schedlock=step we'll always leave threads other than the one with the stepping range locked, while that's not true with the "next" command. With schedlock "step", other threads still run unlocked when "next" detects a function call and steps over it. Whether that makes sense or not, still, it's documented that way in the manual. If another thread hits an event that doesn't cause a stop while the nexting thread steps over a function call, we'll get here and fail the assertion. The fix is just to adjust the assertion. Even though we found the stepping thread, we'll still step-over the breakpoint that just triggered correctly. Surprisingly, gdb.threads/schedlock.exp doesn't have any test that steps over a function call. This commits fixes that. This ensures that "next" doesn't switch focus to another thread, and checks whether other threads run locked or not, depending on scheduler locking mode and command. There's a lot of duplication in that file that this ends cleaning up. There's more that could be cleaned up, but that would end up an unrelated change, best done separately. This new coverage in schedlock.exp happens to trigger the internal error in question, like so: FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (1) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (3) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (5) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (7) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (9) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next does not change thread (switched to thread 0) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: current thread advanced - unlocked (wrong amount) That's because we have more than one thread running the same loop, and while one thread is stepping over a function call, the other thread hits the step-resume breakpoint of the first, which needs to be stepped over, and we end up in switch_back_to_stepped_thread exactly in the problem case. I think a simpler and more directed test is also useful, to not rely on internal breakpoint magics. So this commit also adds a test that has a thread trip on a conditional breakpoint that doesn't cause a user-visible stop while another thread is stepping over a call. That currently fails like this: FAIL: gdb.threads/next-bp-other-thread.exp: schedlock=step: next over function call (GDB internal error) Tested on x86_64 Fedora 20. gdb/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * infrun.c (switch_back_to_stepped_thread): Use currently_stepping instead of assuming a thread with a stepping range is always stepping. gdb/testsuite/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * gdb.threads/schedlock.c (some_function): New function. (call_function): New global. (MAYBE_CALL_SOME_FUNCTION): New macro. (thread_function): Call it. * gdb.threads/schedlock.exp (get_args): Add description parameter, and use it instead of a global counter. Adjust all callers. (get_current_thread): Use "find current thread" for test message here rather than having all callers pass down the same string. (goto_loop): New procedure, factored out from ... (my_continue): ... this. (step_ten_loops): Change parameter from test message to command to use. Adjust. (list_count): Delete global. (check_result): New procedure, factored out from duplicate top level code. (continue tests): Wrap in with_test_prefix. (test_step): New procedure, factored out from duplicate top level code. (top level): Test "step" in combination with all scheduler-locking modes. Test "next" in combination with all scheduler-locking modes, and in combination with stepping over a function call or not. * gdb.threads/next-bp-other-thread.c: New file. * gdb.threads/next-bp-other-thread.exp: New file.
2014-10-29 19:15:39 +01:00
set before_args [get_args "before"]
PR 17408 - assertion failure in switch_back_to_stepped_thread This PR shows that GDB can easily trigger an assertion here, in infrun.c: 5392 /* Did we find the stepping thread? */ 5393 if (tp->control.step_range_end) 5394 { 5395 /* Yep. There should only one though. */ 5396 gdb_assert (stepping_thread == NULL); 5397 5398 /* The event thread is handled at the top, before we 5399 enter this loop. */ 5400 gdb_assert (tp != ecs->event_thread); 5401 5402 /* If some thread other than the event thread is 5403 stepping, then scheduler locking can't be in effect, 5404 otherwise we wouldn't have resumed the current event 5405 thread in the first place. */ 5406 gdb_assert (!schedlock_applies (currently_stepping (tp))); 5407 5408 stepping_thread = tp; 5409 } Like: gdb/infrun.c:5406: internal-error: switch_back_to_stepped_thread: Assertion `!schedlock_applies (1)' failed. The way the assertion is written is assuming that with schedlock=step we'll always leave threads other than the one with the stepping range locked, while that's not true with the "next" command. With schedlock "step", other threads still run unlocked when "next" detects a function call and steps over it. Whether that makes sense or not, still, it's documented that way in the manual. If another thread hits an event that doesn't cause a stop while the nexting thread steps over a function call, we'll get here and fail the assertion. The fix is just to adjust the assertion. Even though we found the stepping thread, we'll still step-over the breakpoint that just triggered correctly. Surprisingly, gdb.threads/schedlock.exp doesn't have any test that steps over a function call. This commits fixes that. This ensures that "next" doesn't switch focus to another thread, and checks whether other threads run locked or not, depending on scheduler locking mode and command. There's a lot of duplication in that file that this ends cleaning up. There's more that could be cleaned up, but that would end up an unrelated change, best done separately. This new coverage in schedlock.exp happens to trigger the internal error in question, like so: FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (1) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (3) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (5) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (7) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (9) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next does not change thread (switched to thread 0) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: current thread advanced - unlocked (wrong amount) That's because we have more than one thread running the same loop, and while one thread is stepping over a function call, the other thread hits the step-resume breakpoint of the first, which needs to be stepped over, and we end up in switch_back_to_stepped_thread exactly in the problem case. I think a simpler and more directed test is also useful, to not rely on internal breakpoint magics. So this commit also adds a test that has a thread trip on a conditional breakpoint that doesn't cause a user-visible stop while another thread is stepping over a call. That currently fails like this: FAIL: gdb.threads/next-bp-other-thread.exp: schedlock=step: next over function call (GDB internal error) Tested on x86_64 Fedora 20. gdb/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * infrun.c (switch_back_to_stepped_thread): Use currently_stepping instead of assuming a thread with a stepping range is always stepping. gdb/testsuite/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * gdb.threads/schedlock.c (some_function): New function. (call_function): New global. (MAYBE_CALL_SOME_FUNCTION): New macro. (thread_function): Call it. * gdb.threads/schedlock.exp (get_args): Add description parameter, and use it instead of a global counter. Adjust all callers. (get_current_thread): Use "find current thread" for test message here rather than having all callers pass down the same string. (goto_loop): New procedure, factored out from ... (my_continue): ... this. (step_ten_loops): Change parameter from test message to command to use. Adjust. (list_count): Delete global. (check_result): New procedure, factored out from duplicate top level code. (continue tests): Wrap in with_test_prefix. (test_step): New procedure, factored out from duplicate top level code. (top level): Test "step" in combination with all scheduler-locking modes. Test "next" in combination with all scheduler-locking modes, and in combination with stepping over a function call or not. * gdb.threads/next-bp-other-thread.c: New file. * gdb.threads/next-bp-other-thread.exp: New file.
2014-10-29 19:15:39 +01:00
step_ten_loops $cmd
Make "set scheduler-locking step" depend on user intention, only Currently, "set scheduler-locking step" is a bit odd. The manual documents it as being optimized for stepping, so that focus of debugging does not change unexpectedly, but then it says that sometimes other threads may run, and thus focus may indeed change unexpectedly... A user can then be excused to get confused and wonder why does GDB behave like this. I don't think a user should have to know about details of how "next" or whatever other run control command is implemented internally to understand when does the "scheduler-locking step" setting take effect. This patch completes a transition that the code has been moving towards for a while. It makes "set scheduler-locking step" hold threads depending on whether the _command_ the user entered was a stepping command [step/stepi/next/nexti], or not. Before, GDB could end up locking threads even on "continue" if for some reason run control decides a thread needs to be single stepped (e.g., for a software watchpoint). After, if a "continue" happens to need to single-step for some reason, we won't lock threads (unless when stepping over a breakpoint, naturally). And if a stepping command wants to continue a thread for bit, like when skipping a function to a step-resume breakpoint, we'll still lock threads, so focus of debugging doesn't change. In order to make this work, we need to record in the thread structure whether what set it running was a stepping command. (A follow up patch will remove the "step" parameters of 'proceed' and 'resume') FWIW, Fedora GDB, which defaults to "scheduler-locking step" (mainline defaults to "off") carries a different patch that goes in this direction as well. Tested on x86_64 Fedora 20, native and gdbserver. gdb/ChangeLog: 2015-03-24 Pedro Alves <palves@redhat.com> * gdbthread.h (struct thread_control_state) <stepping_command>: New field. * infcmd.c (step_once): Pass step=1 to clear_proceed_status. Set the thread's stepping_command field. * infrun.c (resume): Check the thread's stepping_command flag to determine which threads should be resumed. Rename 'entry_step' local to user_step. (clear_proceed_status_thread): Clear 'stepping_command'. (schedlock_applies): Change parameter type to struct thread_info pointer. Adjust. (find_thread_needs_step_over): Remove 'step' parameter. Adjust. (switch_back_to_stepped_thread): Adjust calls to 'schedlock_applies'. (_initialize_infrun): Adjust "set scheduler-locking step" help. gdb/testsuite/ChangeLog: 2015-03-24 Pedro Alves <palves@redhat.com> * gdb.threads/schedlock.exp (test_step): No longer expect that "set scheduler-locking step" with "next" over a function call runs threads unlocked. gdb/doc/ChangeLog: 2015-03-24 Pedro Alves <palves@redhat.com> * gdb.texinfo (test_step) <set scheduler-locking step>: No longer mention that threads may sometimes run unlocked.
2015-03-24 18:50:31 +01:00
if { $schedlock == "on" || $schedlock == "step" } {
PR 17408 - assertion failure in switch_back_to_stepped_thread This PR shows that GDB can easily trigger an assertion here, in infrun.c: 5392 /* Did we find the stepping thread? */ 5393 if (tp->control.step_range_end) 5394 { 5395 /* Yep. There should only one though. */ 5396 gdb_assert (stepping_thread == NULL); 5397 5398 /* The event thread is handled at the top, before we 5399 enter this loop. */ 5400 gdb_assert (tp != ecs->event_thread); 5401 5402 /* If some thread other than the event thread is 5403 stepping, then scheduler locking can't be in effect, 5404 otherwise we wouldn't have resumed the current event 5405 thread in the first place. */ 5406 gdb_assert (!schedlock_applies (currently_stepping (tp))); 5407 5408 stepping_thread = tp; 5409 } Like: gdb/infrun.c:5406: internal-error: switch_back_to_stepped_thread: Assertion `!schedlock_applies (1)' failed. The way the assertion is written is assuming that with schedlock=step we'll always leave threads other than the one with the stepping range locked, while that's not true with the "next" command. With schedlock "step", other threads still run unlocked when "next" detects a function call and steps over it. Whether that makes sense or not, still, it's documented that way in the manual. If another thread hits an event that doesn't cause a stop while the nexting thread steps over a function call, we'll get here and fail the assertion. The fix is just to adjust the assertion. Even though we found the stepping thread, we'll still step-over the breakpoint that just triggered correctly. Surprisingly, gdb.threads/schedlock.exp doesn't have any test that steps over a function call. This commits fixes that. This ensures that "next" doesn't switch focus to another thread, and checks whether other threads run locked or not, depending on scheduler locking mode and command. There's a lot of duplication in that file that this ends cleaning up. There's more that could be cleaned up, but that would end up an unrelated change, best done separately. This new coverage in schedlock.exp happens to trigger the internal error in question, like so: FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (1) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (3) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (5) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (7) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (9) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next does not change thread (switched to thread 0) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: current thread advanced - unlocked (wrong amount) That's because we have more than one thread running the same loop, and while one thread is stepping over a function call, the other thread hits the step-resume breakpoint of the first, which needs to be stepped over, and we end up in switch_back_to_stepped_thread exactly in the problem case. I think a simpler and more directed test is also useful, to not rely on internal breakpoint magics. So this commit also adds a test that has a thread trip on a conditional breakpoint that doesn't cause a user-visible stop while another thread is stepping over a call. That currently fails like this: FAIL: gdb.threads/next-bp-other-thread.exp: schedlock=step: next over function call (GDB internal error) Tested on x86_64 Fedora 20. gdb/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * infrun.c (switch_back_to_stepped_thread): Use currently_stepping instead of assuming a thread with a stepping range is always stepping. gdb/testsuite/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * gdb.threads/schedlock.c (some_function): New function. (call_function): New global. (MAYBE_CALL_SOME_FUNCTION): New macro. (thread_function): Call it. * gdb.threads/schedlock.exp (get_args): Add description parameter, and use it instead of a global counter. Adjust all callers. (get_current_thread): Use "find current thread" for test message here rather than having all callers pass down the same string. (goto_loop): New procedure, factored out from ... (my_continue): ... this. (step_ten_loops): Change parameter from test message to command to use. Adjust. (list_count): Delete global. (check_result): New procedure, factored out from duplicate top level code. (continue tests): Wrap in with_test_prefix. (test_step): New procedure, factored out from duplicate top level code. (top level): Test "step" in combination with all scheduler-locking modes. Test "next" in combination with all scheduler-locking modes, and in combination with stepping over a function call or not. * gdb.threads/next-bp-other-thread.c: New file. * gdb.threads/next-bp-other-thread.exp: New file.
2014-10-29 19:15:39 +01:00
set locked 1
} else {
PR 17408 - assertion failure in switch_back_to_stepped_thread This PR shows that GDB can easily trigger an assertion here, in infrun.c: 5392 /* Did we find the stepping thread? */ 5393 if (tp->control.step_range_end) 5394 { 5395 /* Yep. There should only one though. */ 5396 gdb_assert (stepping_thread == NULL); 5397 5398 /* The event thread is handled at the top, before we 5399 enter this loop. */ 5400 gdb_assert (tp != ecs->event_thread); 5401 5402 /* If some thread other than the event thread is 5403 stepping, then scheduler locking can't be in effect, 5404 otherwise we wouldn't have resumed the current event 5405 thread in the first place. */ 5406 gdb_assert (!schedlock_applies (currently_stepping (tp))); 5407 5408 stepping_thread = tp; 5409 } Like: gdb/infrun.c:5406: internal-error: switch_back_to_stepped_thread: Assertion `!schedlock_applies (1)' failed. The way the assertion is written is assuming that with schedlock=step we'll always leave threads other than the one with the stepping range locked, while that's not true with the "next" command. With schedlock "step", other threads still run unlocked when "next" detects a function call and steps over it. Whether that makes sense or not, still, it's documented that way in the manual. If another thread hits an event that doesn't cause a stop while the nexting thread steps over a function call, we'll get here and fail the assertion. The fix is just to adjust the assertion. Even though we found the stepping thread, we'll still step-over the breakpoint that just triggered correctly. Surprisingly, gdb.threads/schedlock.exp doesn't have any test that steps over a function call. This commits fixes that. This ensures that "next" doesn't switch focus to another thread, and checks whether other threads run locked or not, depending on scheduler locking mode and command. There's a lot of duplication in that file that this ends cleaning up. There's more that could be cleaned up, but that would end up an unrelated change, best done separately. This new coverage in schedlock.exp happens to trigger the internal error in question, like so: FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (1) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (3) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (5) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (7) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (9) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next does not change thread (switched to thread 0) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: current thread advanced - unlocked (wrong amount) That's because we have more than one thread running the same loop, and while one thread is stepping over a function call, the other thread hits the step-resume breakpoint of the first, which needs to be stepped over, and we end up in switch_back_to_stepped_thread exactly in the problem case. I think a simpler and more directed test is also useful, to not rely on internal breakpoint magics. So this commit also adds a test that has a thread trip on a conditional breakpoint that doesn't cause a user-visible stop while another thread is stepping over a call. That currently fails like this: FAIL: gdb.threads/next-bp-other-thread.exp: schedlock=step: next over function call (GDB internal error) Tested on x86_64 Fedora 20. gdb/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * infrun.c (switch_back_to_stepped_thread): Use currently_stepping instead of assuming a thread with a stepping range is always stepping. gdb/testsuite/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * gdb.threads/schedlock.c (some_function): New function. (call_function): New global. (MAYBE_CALL_SOME_FUNCTION): New macro. (thread_function): Call it. * gdb.threads/schedlock.exp (get_args): Add description parameter, and use it instead of a global counter. Adjust all callers. (get_current_thread): Use "find current thread" for test message here rather than having all callers pass down the same string. (goto_loop): New procedure, factored out from ... (my_continue): ... this. (step_ten_loops): Change parameter from test message to command to use. Adjust. (list_count): Delete global. (check_result): New procedure, factored out from duplicate top level code. (continue tests): Wrap in with_test_prefix. (test_step): New procedure, factored out from duplicate top level code. (top level): Test "step" in combination with all scheduler-locking modes. Test "next" in combination with all scheduler-locking modes, and in combination with stepping over a function call or not. * gdb.threads/next-bp-other-thread.c: New file. * gdb.threads/next-bp-other-thread.exp: New file.
2014-10-29 19:15:39 +01:00
set locked 0
}
PR 17408 - assertion failure in switch_back_to_stepped_thread This PR shows that GDB can easily trigger an assertion here, in infrun.c: 5392 /* Did we find the stepping thread? */ 5393 if (tp->control.step_range_end) 5394 { 5395 /* Yep. There should only one though. */ 5396 gdb_assert (stepping_thread == NULL); 5397 5398 /* The event thread is handled at the top, before we 5399 enter this loop. */ 5400 gdb_assert (tp != ecs->event_thread); 5401 5402 /* If some thread other than the event thread is 5403 stepping, then scheduler locking can't be in effect, 5404 otherwise we wouldn't have resumed the current event 5405 thread in the first place. */ 5406 gdb_assert (!schedlock_applies (currently_stepping (tp))); 5407 5408 stepping_thread = tp; 5409 } Like: gdb/infrun.c:5406: internal-error: switch_back_to_stepped_thread: Assertion `!schedlock_applies (1)' failed. The way the assertion is written is assuming that with schedlock=step we'll always leave threads other than the one with the stepping range locked, while that's not true with the "next" command. With schedlock "step", other threads still run unlocked when "next" detects a function call and steps over it. Whether that makes sense or not, still, it's documented that way in the manual. If another thread hits an event that doesn't cause a stop while the nexting thread steps over a function call, we'll get here and fail the assertion. The fix is just to adjust the assertion. Even though we found the stepping thread, we'll still step-over the breakpoint that just triggered correctly. Surprisingly, gdb.threads/schedlock.exp doesn't have any test that steps over a function call. This commits fixes that. This ensures that "next" doesn't switch focus to another thread, and checks whether other threads run locked or not, depending on scheduler locking mode and command. There's a lot of duplication in that file that this ends cleaning up. There's more that could be cleaned up, but that would end up an unrelated change, best done separately. This new coverage in schedlock.exp happens to trigger the internal error in question, like so: FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (1) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (3) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (5) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (7) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (9) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next does not change thread (switched to thread 0) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: current thread advanced - unlocked (wrong amount) That's because we have more than one thread running the same loop, and while one thread is stepping over a function call, the other thread hits the step-resume breakpoint of the first, which needs to be stepped over, and we end up in switch_back_to_stepped_thread exactly in the problem case. I think a simpler and more directed test is also useful, to not rely on internal breakpoint magics. So this commit also adds a test that has a thread trip on a conditional breakpoint that doesn't cause a user-visible stop while another thread is stepping over a call. That currently fails like this: FAIL: gdb.threads/next-bp-other-thread.exp: schedlock=step: next over function call (GDB internal error) Tested on x86_64 Fedora 20. gdb/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * infrun.c (switch_back_to_stepped_thread): Use currently_stepping instead of assuming a thread with a stepping range is always stepping. gdb/testsuite/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * gdb.threads/schedlock.c (some_function): New function. (call_function): New global. (MAYBE_CALL_SOME_FUNCTION): New macro. (thread_function): Call it. * gdb.threads/schedlock.exp (get_args): Add description parameter, and use it instead of a global counter. Adjust all callers. (get_current_thread): Use "find current thread" for test message here rather than having all callers pass down the same string. (goto_loop): New procedure, factored out from ... (my_continue): ... this. (step_ten_loops): Change parameter from test message to command to use. Adjust. (list_count): Delete global. (check_result): New procedure, factored out from duplicate top level code. (continue tests): Wrap in with_test_prefix. (test_step): New procedure, factored out from duplicate top level code. (top level): Test "step" in combination with all scheduler-locking modes. Test "next" in combination with all scheduler-locking modes, and in combination with stepping over a function call or not. * gdb.threads/next-bp-other-thread.c: New file. * gdb.threads/next-bp-other-thread.exp: New file.
2014-10-29 19:15:39 +01:00
check_result $cmd $curthread $before_args $locked
}
PR 17408 - assertion failure in switch_back_to_stepped_thread This PR shows that GDB can easily trigger an assertion here, in infrun.c: 5392 /* Did we find the stepping thread? */ 5393 if (tp->control.step_range_end) 5394 { 5395 /* Yep. There should only one though. */ 5396 gdb_assert (stepping_thread == NULL); 5397 5398 /* The event thread is handled at the top, before we 5399 enter this loop. */ 5400 gdb_assert (tp != ecs->event_thread); 5401 5402 /* If some thread other than the event thread is 5403 stepping, then scheduler locking can't be in effect, 5404 otherwise we wouldn't have resumed the current event 5405 thread in the first place. */ 5406 gdb_assert (!schedlock_applies (currently_stepping (tp))); 5407 5408 stepping_thread = tp; 5409 } Like: gdb/infrun.c:5406: internal-error: switch_back_to_stepped_thread: Assertion `!schedlock_applies (1)' failed. The way the assertion is written is assuming that with schedlock=step we'll always leave threads other than the one with the stepping range locked, while that's not true with the "next" command. With schedlock "step", other threads still run unlocked when "next" detects a function call and steps over it. Whether that makes sense or not, still, it's documented that way in the manual. If another thread hits an event that doesn't cause a stop while the nexting thread steps over a function call, we'll get here and fail the assertion. The fix is just to adjust the assertion. Even though we found the stepping thread, we'll still step-over the breakpoint that just triggered correctly. Surprisingly, gdb.threads/schedlock.exp doesn't have any test that steps over a function call. This commits fixes that. This ensures that "next" doesn't switch focus to another thread, and checks whether other threads run locked or not, depending on scheduler locking mode and command. There's a lot of duplication in that file that this ends cleaning up. There's more that could be cleaned up, but that would end up an unrelated change, best done separately. This new coverage in schedlock.exp happens to trigger the internal error in question, like so: FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (1) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (3) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (5) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (7) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (9) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next does not change thread (switched to thread 0) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: current thread advanced - unlocked (wrong amount) That's because we have more than one thread running the same loop, and while one thread is stepping over a function call, the other thread hits the step-resume breakpoint of the first, which needs to be stepped over, and we end up in switch_back_to_stepped_thread exactly in the problem case. I think a simpler and more directed test is also useful, to not rely on internal breakpoint magics. So this commit also adds a test that has a thread trip on a conditional breakpoint that doesn't cause a user-visible stop while another thread is stepping over a call. That currently fails like this: FAIL: gdb.threads/next-bp-other-thread.exp: schedlock=step: next over function call (GDB internal error) Tested on x86_64 Fedora 20. gdb/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * infrun.c (switch_back_to_stepped_thread): Use currently_stepping instead of assuming a thread with a stepping range is always stepping. gdb/testsuite/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * gdb.threads/schedlock.c (some_function): New function. (call_function): New global. (MAYBE_CALL_SOME_FUNCTION): New macro. (thread_function): Call it. * gdb.threads/schedlock.exp (get_args): Add description parameter, and use it instead of a global counter. Adjust all callers. (get_current_thread): Use "find current thread" for test message here rather than having all callers pass down the same string. (goto_loop): New procedure, factored out from ... (my_continue): ... this. (step_ten_loops): Change parameter from test message to command to use. Adjust. (list_count): Delete global. (check_result): New procedure, factored out from duplicate top level code. (continue tests): Wrap in with_test_prefix. (test_step): New procedure, factored out from duplicate top level code. (top level): Test "step" in combination with all scheduler-locking modes. Test "next" in combination with all scheduler-locking modes, and in combination with stepping over a function call or not. * gdb.threads/next-bp-other-thread.c: New file. * gdb.threads/next-bp-other-thread.exp: New file.
2014-10-29 19:15:39 +01:00
# Test stepping/nexting with different modes of scheduler locking.
foreach schedlock {"off" "step" "on"} {
with_test_prefix "schedlock=$schedlock" {
with_test_prefix "cmd=step" {
test_step $schedlock "step" 0
}
with_test_prefix "cmd=next" {
Make "set scheduler-locking step" depend on user intention, only Currently, "set scheduler-locking step" is a bit odd. The manual documents it as being optimized for stepping, so that focus of debugging does not change unexpectedly, but then it says that sometimes other threads may run, and thus focus may indeed change unexpectedly... A user can then be excused to get confused and wonder why does GDB behave like this. I don't think a user should have to know about details of how "next" or whatever other run control command is implemented internally to understand when does the "scheduler-locking step" setting take effect. This patch completes a transition that the code has been moving towards for a while. It makes "set scheduler-locking step" hold threads depending on whether the _command_ the user entered was a stepping command [step/stepi/next/nexti], or not. Before, GDB could end up locking threads even on "continue" if for some reason run control decides a thread needs to be single stepped (e.g., for a software watchpoint). After, if a "continue" happens to need to single-step for some reason, we won't lock threads (unless when stepping over a breakpoint, naturally). And if a stepping command wants to continue a thread for bit, like when skipping a function to a step-resume breakpoint, we'll still lock threads, so focus of debugging doesn't change. In order to make this work, we need to record in the thread structure whether what set it running was a stepping command. (A follow up patch will remove the "step" parameters of 'proceed' and 'resume') FWIW, Fedora GDB, which defaults to "scheduler-locking step" (mainline defaults to "off") carries a different patch that goes in this direction as well. Tested on x86_64 Fedora 20, native and gdbserver. gdb/ChangeLog: 2015-03-24 Pedro Alves <palves@redhat.com> * gdbthread.h (struct thread_control_state) <stepping_command>: New field. * infcmd.c (step_once): Pass step=1 to clear_proceed_status. Set the thread's stepping_command field. * infrun.c (resume): Check the thread's stepping_command flag to determine which threads should be resumed. Rename 'entry_step' local to user_step. (clear_proceed_status_thread): Clear 'stepping_command'. (schedlock_applies): Change parameter type to struct thread_info pointer. Adjust. (find_thread_needs_step_over): Remove 'step' parameter. Adjust. (switch_back_to_stepped_thread): Adjust calls to 'schedlock_applies'. (_initialize_infrun): Adjust "set scheduler-locking step" help. gdb/testsuite/ChangeLog: 2015-03-24 Pedro Alves <palves@redhat.com> * gdb.threads/schedlock.exp (test_step): No longer expect that "set scheduler-locking step" with "next" over a function call runs threads unlocked. gdb/doc/ChangeLog: 2015-03-24 Pedro Alves <palves@redhat.com> * gdb.texinfo (test_step) <set scheduler-locking step>: No longer mention that threads may sometimes run unlocked.
2015-03-24 18:50:31 +01:00
# In GDB <= 7.9, with schedlock "step", "next" would
# unlock threads when stepping over a function call. This
# exercises "next" with and without a function call. WRT
# "schedlock step", "next" should behave just like "step".
PR 17408 - assertion failure in switch_back_to_stepped_thread This PR shows that GDB can easily trigger an assertion here, in infrun.c: 5392 /* Did we find the stepping thread? */ 5393 if (tp->control.step_range_end) 5394 { 5395 /* Yep. There should only one though. */ 5396 gdb_assert (stepping_thread == NULL); 5397 5398 /* The event thread is handled at the top, before we 5399 enter this loop. */ 5400 gdb_assert (tp != ecs->event_thread); 5401 5402 /* If some thread other than the event thread is 5403 stepping, then scheduler locking can't be in effect, 5404 otherwise we wouldn't have resumed the current event 5405 thread in the first place. */ 5406 gdb_assert (!schedlock_applies (currently_stepping (tp))); 5407 5408 stepping_thread = tp; 5409 } Like: gdb/infrun.c:5406: internal-error: switch_back_to_stepped_thread: Assertion `!schedlock_applies (1)' failed. The way the assertion is written is assuming that with schedlock=step we'll always leave threads other than the one with the stepping range locked, while that's not true with the "next" command. With schedlock "step", other threads still run unlocked when "next" detects a function call and steps over it. Whether that makes sense or not, still, it's documented that way in the manual. If another thread hits an event that doesn't cause a stop while the nexting thread steps over a function call, we'll get here and fail the assertion. The fix is just to adjust the assertion. Even though we found the stepping thread, we'll still step-over the breakpoint that just triggered correctly. Surprisingly, gdb.threads/schedlock.exp doesn't have any test that steps over a function call. This commits fixes that. This ensures that "next" doesn't switch focus to another thread, and checks whether other threads run locked or not, depending on scheduler locking mode and command. There's a lot of duplication in that file that this ends cleaning up. There's more that could be cleaned up, but that would end up an unrelated change, best done separately. This new coverage in schedlock.exp happens to trigger the internal error in question, like so: FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (1) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (3) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (5) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (7) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (9) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next does not change thread (switched to thread 0) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: current thread advanced - unlocked (wrong amount) That's because we have more than one thread running the same loop, and while one thread is stepping over a function call, the other thread hits the step-resume breakpoint of the first, which needs to be stepped over, and we end up in switch_back_to_stepped_thread exactly in the problem case. I think a simpler and more directed test is also useful, to not rely on internal breakpoint magics. So this commit also adds a test that has a thread trip on a conditional breakpoint that doesn't cause a user-visible stop while another thread is stepping over a call. That currently fails like this: FAIL: gdb.threads/next-bp-other-thread.exp: schedlock=step: next over function call (GDB internal error) Tested on x86_64 Fedora 20. gdb/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * infrun.c (switch_back_to_stepped_thread): Use currently_stepping instead of assuming a thread with a stepping range is always stepping. gdb/testsuite/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * gdb.threads/schedlock.c (some_function): New function. (call_function): New global. (MAYBE_CALL_SOME_FUNCTION): New macro. (thread_function): Call it. * gdb.threads/schedlock.exp (get_args): Add description parameter, and use it instead of a global counter. Adjust all callers. (get_current_thread): Use "find current thread" for test message here rather than having all callers pass down the same string. (goto_loop): New procedure, factored out from ... (my_continue): ... this. (step_ten_loops): Change parameter from test message to command to use. Adjust. (list_count): Delete global. (check_result): New procedure, factored out from duplicate top level code. (continue tests): Wrap in with_test_prefix. (test_step): New procedure, factored out from duplicate top level code. (top level): Test "step" in combination with all scheduler-locking modes. Test "next" in combination with all scheduler-locking modes, and in combination with stepping over a function call or not. * gdb.threads/next-bp-other-thread.c: New file. * gdb.threads/next-bp-other-thread.exp: New file.
2014-10-29 19:15:39 +01:00
foreach call_function {0 1} {
with_test_prefix "call_function=$call_function" {
test_step $schedlock "next" $call_function
}
}
}
}
}