From ab917dfb5ae0952c234a9bfa16bb3122fdfaf14c Mon Sep 17 00:00:00 2001 From: Pedro Alves Date: Wed, 29 Oct 2014 18:25:27 +0000 Subject: [PATCH] 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 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 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. --- gdb/ChangeLog | 7 +++++++ gdb/testsuite/ChangeLog | 28 ++++++++++++++++++++++++++++ 2 files changed, 35 insertions(+) diff --git a/gdb/ChangeLog b/gdb/ChangeLog index 0aa99c6fc13..66351eafee5 100644 --- a/gdb/ChangeLog +++ b/gdb/ChangeLog @@ -1,3 +1,10 @@ +2014-10-29 Pedro Alves + + 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. + 2014-10-29 Pedro Alves PR python/17372 diff --git a/gdb/testsuite/ChangeLog b/gdb/testsuite/ChangeLog index 367187ab9c6..e4a2bf62b59 100644 --- a/gdb/testsuite/ChangeLog +++ b/gdb/testsuite/ChangeLog @@ -1,3 +1,31 @@ +2014-10-29 Pedro Alves + + 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 Pedro Alves PR python/17372 -- 2.30.2