Bug 16292 - GDB Oversteps a range in some cases.
Summary: GDB Oversteps a range in some cases.
Status: RESOLVED FIXED
Alias: None
Product: gdb
Classification: Unclassified
Component: breakpoints (show other bugs)
Version: HEAD
: P2 normal
Target Milestone: ---
Assignee: Pedro Alves
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-12-04 19:16 UTC by Sterling Augustine
Modified: 2014-05-17 08:30 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments
Log from top of trunk with quite a bit of additional logging statements (795.62 KB, text/x-log)
2014-01-22 17:22 UTC, Sterling Augustine
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Sterling Augustine 2013-12-04 19:16:50 UTC
Log below shows gdb 7.6, but I have reprod with top of trunk.

Situation is a heavily multi-threaded application, setting a breakpoint and stepping over a line or two with "n". We have also seen it with "fin". More details to follow.

I have unsuccessfully tried to find a small test case, but at least one place this happens is while debugging the chrome web browser, which is very much not small.

../../gdb-7.6.x/gdb/infrun.c:1965: internal-error: resume: Assertion `pc_in_thread_step_range (pc, tp)' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) y

Some work has been done here that isn't quite right, but is at least in the neighborhood. 

https://github.com/palves/gdb/commit/b6b55ba610f8db5d89ec7405c93013a10d9a1c20
https://github.com/palves/gdb/commit/1d56ddf439b6f7e7fa9759cf1f8e02106eea6af5
Comment 1 Sterling Augustine 2013-12-04 19:17:50 UTC
Google Ref: 11033327
Comment 2 Sterling Augustine 2014-01-22 17:22:15 UTC
Created attachment 7368 [details]
Log from top of trunk with quite a bit of additional logging statements
Comment 3 Pedro Alves 2014-02-26 14:07:20 UTC
Fix was fixed by d137e6dc798cdf3b3b17fe47322ce61450870e22 :   

Make sure we don't resume the stepped thread by accident.
...
    gdb/
    2014-02-07  Pedro Alves  <palves@redhat.com>
    
        * infrun.c (handle_signal_stop) <signal arrives while stepping
        over a breakpoint>: Switch back to the stepping thread.
    
    gdb/testsuite/
    2014-02-07  Pedro Alves  <pedro@codesourcery.com>
            Pedro Alves  <palves@redhat.com>
    
        * gdb.threads/step-after-sr-lock.c: New file.
        * gdb.threads/step-after-sr-lock.exp: New file.

I think this fix should go into 7.7.
Comment 4 Pedro Alves 2014-02-26 14:07:36 UTC
7.7.1...
Comment 5 Sourceware Commits 2014-02-26 16:43:59 UTC
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  0dcb32c3ae07166fc3b04eb4a86ae93ecd87bfb8 (commit)
      from  f2fce0ca3dd5e0dc37fabb75e8874c05e8bf5170 (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=0dcb32c3ae07166fc3b04eb4a86ae93ecd87bfb8

commit 0dcb32c3ae07166fc3b04eb4a86ae93ecd87bfb8
Author: Pedro Alves <palves@redhat.com>
Date:   Wed Feb 26 16:33:13 2014 +0000

    Mention PR breakpoints/16292 in corresponding ChangeLog entry.

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

Summary of changes:
 gdb/ChangeLog |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)
Comment 6 Sourceware Commits 2014-02-26 17:07:38 UTC
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, gdb-7.7-branch has been updated
       via  8fd1f4997cebf077f06a4c8c6e08cb54697a25d7 (commit)
      from  95bffc909f350e40df08c66f8d0bc96f087a1bbd (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=8fd1f4997cebf077f06a4c8c6e08cb54697a25d7

commit 8fd1f4997cebf077f06a4c8c6e08cb54697a25d7
Author: Pedro Alves <palves@redhat.com>
Date:   Wed Feb 26 16:52:24 2014 +0000

    Make sure we don't resume the stepped thread by accident.
    
    Say:
    
    <stopped at a breakpoint in thread 2>
    (gdb) thread 3
    (gdb) step
    
    The above triggers the prepare_to_proceed/deferred_step_ptid process,
    which switches back to thread 2, to step over its breakpoint before
    getting back to thread 3 and "step" it.
    
    If while stepping over the breakpoint in thread 2, a signal arrives,
    and it is set to pass/nostop, we'll set a step-resume breakpoint at
    the supposed signal-handler resume address, and call keep_going.  The
    problem is that we were supposedly stepping thread 3, and that
    keep_going delivers a signal to thread 2, and due to scheduler-locking
    off, resumes everything else, _including_ thread 3, the thread we want
    stepping.  This means that we lose control of thread 3 until the next
    event, when we stop everything.  The end result for the user, is that
    GDB lost control of the "step".
    
    Here's the current infrun debug output of the above, with the testcase
    in the patch below:
    
    infrun: clear_proceed_status_thread (Thread 0x2aaaab8f5700 (LWP 11663))
    infrun: clear_proceed_status_thread (Thread 0x2aaaab6f4700 (LWP 11662))
    infrun: clear_proceed_status_thread (Thread 0x2aaaab4f2b20 (LWP 11659))
    infrun: proceed (addr=0xffffffffffffffff, signal=144, step=1)
    infrun: prepare_to_proceed (step=1), switched to [Thread 0x2aaaab6f4700 (LWP 11662)]
    infrun: resume (step=1, signal=0), trap_expected=1, current thread [Thread 0x2aaaab6f4700 (LWP 11662)] at 0x40098f
    infrun: wait_for_inferior ()
    infrun: target_wait (-1, status) =
    infrun:   11659 [Thread 0x2aaaab6f4700 (LWP 11662)],
    infrun:   status->kind = stopped, signal = SIGUSR1
    infrun: infwait_normal_state
    infrun: TARGET_WAITKIND_STOPPED
    infrun: stop_pc = 0x40098f
    infrun: random signal 30
    
    Program received signal SIGUSR1, User defined signal 1.
    infrun: signal arrived while stepping over breakpoint
    infrun: inserting step-resume breakpoint at 0x40098f
    infrun: resume (step=0, signal=30), trap_expected=0, current thread [Thread 0x2aaaab6f4700 (LWP 11662)] at 0x40098f
    
    ^^^ this is a wildcard resume.
    
    infrun: prepare_to_wait
    infrun: target_wait (-1, status) =
    infrun:   11659 [Thread 0x2aaaab6f4700 (LWP 11662)],
    infrun:   status->kind = stopped, signal = SIGTRAP
    infrun: infwait_normal_state
    infrun: TARGET_WAITKIND_STOPPED
    infrun: stop_pc = 0x40098f
    infrun: BPSTAT_WHAT_STEP_RESUME
    infrun: resume (step=1, signal=0), trap_expected=1, current thread [Thread 0x2aaaab6f4700 (LWP 11662)] at 0x40098f
    
    ^^^ step-resume hit, meaning the handler returned, so we go back to stepping thread 3.
    
    infrun: prepare_to_wait
    infrun: target_wait (-1, status) =
    infrun:   11659 [Thread 0x2aaaab6f4700 (LWP 11662)],
    infrun:   status->kind = stopped, signal = SIGTRAP
    infrun: infwait_normal_state
    infrun: TARGET_WAITKIND_STOPPED
    
    infrun: stop_pc = 0x40088b
    infrun: switching back to stepped thread
    infrun: Switching context from Thread 0x2aaaab6f4700 (LWP 11662) to Thread 0x2aaaab8f5700 (LWP 11663)
    infrun: resume (step=1, signal=0), trap_expected=0, current thread [Thread 0x2aaaab8f5700 (LWP 11663)] at 0x400938
    infrun: prepare_to_wait
    infrun: target_wait (-1, status) =
    infrun:   11659 [Thread 0x2aaaab8f5700 (LWP 11663)],
    infrun:   status->kind = stopped, signal = SIGTRAP
    infrun: infwait_normal_state
    infrun: TARGET_WAITKIND_STOPPED
    infrun: stop_pc = 0x40093a
    infrun: keep going
    infrun: resume (step=1, signal=0), trap_expected=0, current thread [Thread 0x2aaaab8f5700 (LWP 11663)] at 0x40093a
    infrun: prepare_to_wait
    infrun: target_wait (-1, status) =
    infrun:   11659 [Thread 0x2aaaab8f5700 (LWP 11663)],
    infrun:   status->kind = stopped, signal = SIGTRAP
    infrun: infwait_normal_state
    infrun: TARGET_WAITKIND_STOPPED
    infrun: stop_pc = 0x40091e
    infrun: stepped to a different line
    infrun: stop_stepping
    [Switching to Thread 0x2aaaab8f5700 (LWP 11663)]
    69            (*myp) ++; /* set breakpoint child_two here */
    
    ^^^ we stopped at the wrong line.  We still stepped a bit because the
    test is running in a loop, and when we got back to stepping thread 3,
    it happened to be in the stepping range.  (The loop increments a
    counter, and the test makes sure it increments exactly once.  Without
    the fix, the counter increments a bunch, since the user-stepped thread
    runs free without GDB noticing.)
    
    The fix is to switch to the stepping thread before continuing for the
    step-resume breakpoint.
    
    gdb/
    2014-02-26  Pedro Alves  <palves@redhat.com>
    
    	PR breakpoints/16292
    	* infrun.c (handle_signal_stop) <signal arrives while stepping
    	over a breakpoint>: Switch back to the stepping thread.
    
    gdb/testsuite/
    2014-02-26  Pedro Alves  <pedro@codesourcery.com>
    	    Pedro Alves  <palves@redhat.com>
    
    	PR breakpoints/16292
    	* gdb.threads/signal-while-stepping-over-bp-other-thread.c: New
    	file.
    	* gdb.threads/signal-while-stepping-over-bp-other-threadexp: New
    	file.

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

Summary of changes:
 gdb/ChangeLog                                      |    6 +
 gdb/infrun.c                                       |    6 +-
 gdb/testsuite/ChangeLog                            |    9 ++
 .../signal-while-stepping-over-bp-other-thread.c   |  145 ++++++++++++++++++++
 .../signal-while-stepping-over-bp-other-thread.exp |  120 ++++++++++++++++
 5 files changed, 285 insertions(+), 1 deletions(-)
 create mode 100644 gdb/testsuite/gdb.threads/signal-while-stepping-over-bp-other-thread.c
 create mode 100644 gdb/testsuite/gdb.threads/signal-while-stepping-over-bp-other-thread.exp