[Bug threads/18127] threads spawned by infcall end up stuck in "running" state

["cvs-commit at gcc dot gnu.org" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=18127

--- Comment #5 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Pedro Alves <palves@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=28bf096c62d7da6b349605f3940f4c586a850f78

commit 28bf096c62d7da6b349605f3940f4c586a850f78
Author: Pedro Alves <palves@redhat.com>
Date:   Mon Jun 29 16:07:57 2015 +0100

    PR threads/18127 - threads spawned by infcall end up stuck in "running"
state

    Refs:
     https://sourceware.org/ml/gdb/2015-03/msg00024.html
     https://sourceware.org/ml/gdb/2015-06/msg00005.html

    On GNU/Linux, if an infcall spawns a thread, that thread ends up with
    stuck running state.  This happens because:

     - when linux-nat.c detects a new thread, it marks them as running,
       and does not report anything to the core.

     - we skip finish_thread_state when the thread that is running the
       infcall stops.

    As result, that new thread ends up with stuck "running" state, even
    though it really is stopped.

    On Windows, _all_ threads end up stuck in running state, not just the
    one that was spawned.  That happens because when a new thread is
    detected, unlike linux-nat.c, windows-nat.c reports
    TARGET_WAITKIND_SPURIOUS to infrun.  It's the fact that that event
    does not cause a user-visible stop that triggers the problem.  When
    the target is re-resumed, we call set_running with a wildcard ptid,
    which marks all thread as running.  That set_running is not suppressed
    because the (leader) thread being resumed does not have in_infcall
    set.  Later, when the infcall finally finishes successfully, nothing
    marks all threads back to stopped.

    We can trigger the same problem on all targets by having a thread
    other than the one that is running the infcall report a breakpoint hit
    to infrun, and then have that breakpoint not cause a stop.  That's
    what the included test does.

    The fix is to stop GDB from suppressing the set_running calls while
    doing an infcall, and then set the threads back to stopped when the
    call finishes, iff they were originally stopped before the infcall
    started.  (Note the MI *running/*stopped event suppression isn't
    affected.)

    Tested on x86_64 GNU/Linux.

    gdb/ChangeLog:
    2015-06-29  Pedro Alves  <palves@redhat.com>

        PR threads/18127
        * infcall.c (run_inferior_call): On infcall success, if the thread
        was marked stopped before, reset it back to stopped.
        * infrun.c (resume): Don't suppress the set_running calls when
        doing an infcall.
        (normal_stop): Only discard the finish_thread_state cleanup if the
        infcall succeeded.

    gdb/testsuite/ChangeLog:
    2015-06-29  Pedro Alves  <palves@redhat.com>

        PR threads/18127
        * gdb.threads/hand-call-new-thread.c: New file.
        * gdb.threads/hand-call-new-thread.c: New file.

-- 
You are receiving this mail because:
You are on the CC list for the bug.