gdb and binutils branch master updated. 354204061c1eec5cec6e8bab0af164a267b1e67d

[palves at sourceware dot org]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "gdb and binutils".

The branch, master has been updated
       via  354204061c1eec5cec6e8bab0af164a267b1e67d (commit)
      from  d3d4baedb6d247c6372678edd15195a1a93c2c6c (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=354204061c1eec5cec6e8bab0af164a267b1e67d

commit 354204061c1eec5cec6e8bab0af164a267b1e67d
Author: Pedro Alves <palves@redhat.com>
Date:   Wed Oct 29 18:15:39 2014 +0000

    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.

-----------------------------------------------------------------------

Summary of changes:
 gdb/infrun.c                                       |    2 +-
 gdb/testsuite/gdb.threads/next-bp-other-thread.c   |   45 ++++
 gdb/testsuite/gdb.threads/next-bp-other-thread.exp |   54 +++++
 gdb/testsuite/gdb.threads/schedlock.c              |   24 ++-
 gdb/testsuite/gdb.threads/schedlock.exp            |  250 ++++++++++----------
 5 files changed, 254 insertions(+), 121 deletions(-)
 create mode 100644 gdb/testsuite/gdb.threads/next-bp-other-thread.c
 create mode 100644 gdb/testsuite/gdb.threads/next-bp-other-thread.exp


hooks/post-receive
-- 
gdb and binutils