[Bug remote/19496] fork test failures in gdb.threads/forking-threads-plus-breakpoint with remote target

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

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

--- Comment #6 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=0d5b594f86aa7c8f38487802f75841460ab705bf

commit 0d5b594f86aa7c8f38487802f75841460ab705bf
Author: Pedro Alves <palves@redhat.com>
Date:   Thu Mar 17 10:21:37 2016 +0000

    PR remote/19496, timeout in forking-threads-plus-bkpt

    This patch addresses a failure in
    gdb.threads/forking-threads-plus-breakpoint.exp:

    FAIL: gdb.threads/forking-threads-plus-breakpoint.exp: cond_bp_target=1:
    detach_on_fork=on: inferior 1 exited (timeout)

    Cause:

    A fork event was reported to GDB before GDB knew about the parent
    thread, followed immediately by a breakpoint event in a different
    thread.  The parent thread was subsequently added via
    remote_notice_new_inferior in process_stop_reply, but when the thread
    was added the thread_info.state was set to THREAD_STOPPED.  The fork
    event was then handled correctly, but when the fork parent was resumed
    via a call to keep_going, the state was unchanged.

    The breakpoint event was then handled, which caused all the
    non-breakpoint threads to be stopped.  When the breakpoint thread was
    resumed, all the non-breakpoint threads were resumed via
    infrun.c:restart_threads.  Our old fork parent wasn't restarted,
    because it still had thread_info.state set to THREAD_STOPPED.
    Ultimately the program under debug hung waiting for a pthread_join
    while the old fork parent was stopped forever by GDB.

    Fix:

    Since this is non-stop, then the bug is that the thread should have
    been added in THREAD_RUNNING state.  Consider that infrun may be
    pulling target events out of the target_ops backend into its own event
    queue, but, not process them immediately.  E.g., infrun may be
    stopping all threads temporarily for a step-over-breakpoint operation
    for thread A (stop_all_threads).  The waitstatus of all threads is
    thus left pending in the thread structure (save_status), including the
    fork event of thread B.  Right at this point, if the user does "info
    threads", that should show thread B (the fork parent) running, not
    stopped, even if internally, gdb is holding it paused for a little
    bit.

    Thus if in non-stop mode, always add new threads in the external
    user-visible THREAD_RUNNING state.  Change remote_notice_new_inferior
    to accept the internal executing state of the thread instead, with
    EXECUTING set to 1 when we discover a thread that is running on the
    target (such as through remote_update_thread_list), and 0 when the
    thread is really paused (such as when we see a stop reply).

    Tested on x86_64 Linux and Nios II Linux target with x86 Linux host.

    gdb/ChangeLog:
    2016-03-17  Pedro Alves  <palves@redhat.com>
            Don Breazeal  <donb@codesourcery.com>

        PR remote/19496
        * infcmd.c (notice_new_inferior): Use the 'leave_running' argument
        instead of checking the 'non_stop' global.
        * remote.c (remote_add_thread): New parameter 'executing'.  Use it
        to set the new thread's executing state.
        (remote_notice_new_inferior): Rename parameter 'running' to
        'executing'.  Always set the thread state to THREAD_RUNNING in
        non-stop mode, and to THREAD_STOPPED in all-stop mode.  Pass
        EXECUTING to remote_add_thread and notice_new_inferior.
        (remote_update_thread_list): Update to pass executing state, not
        running state.

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