[Bug gdb/28275] commit_resumed_state assertion failure when killing running inferior and running again

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

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

--- Comment #13 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Simon Marchi <simark@sourceware.org>:

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

commit ed14d866a31625c6f8c2cb6d4a445a8372b46161
Author: Simon Marchi <simon.marchi@efficios.com>
Date:   Mon Nov 21 12:12:13 2022 -0500

    gdb: disable commit resumed in target_kill

    New in this version:

     - Better comment in target_kill
     - Uncomment line in test to avoid hanging when exiting, when testing on
       native-extended-gdbserver

    PR 28275 shows that doing a sequence of:

     - Run inferior in background (run &)
     - kill that inferior
     - Run again

    We get into this assertion:

        /home/smarchi/src/binutils-gdb/gdb/target.c:2590: internal-error:
target_wait: Assertion `!proc_target->commit_resumed_state' failed.

        #0  internal_error_loc (file=0x5606b344e740
"/home/smarchi/src/binutils-gdb/gdb/target.c", line=2590, fmt=0x5606b344d6a0
"%s: Assertion `%s' failed.") at
/home/smarchi/src/binutils-gdb/gdbsupport/errors.cc:54
        #1  0x00005606b6296475 in target_wait (ptid=..., status=0x7fffb9390630,
options=...) at /home/smarchi/src/binutils-gdb/gdb/target.c:2590
        #2  0x00005606b5767a98 in startup_inferior (proc_target=0x5606bfccb2a0
<the_amd64_linux_nat_target>, pid=3884857, ntraps=1, last_waitstatus=0x0,
last_ptid=0x0) at /home/smarchi/src/binutils-gdb/gdb/nat/fork-inferior.c:482
        #3  0x00005606b4e6c9c5 in gdb_startup_inferior (pid=3884857,
num_traps=1) at /home/smarchi/src/binutils-gdb/gdb/fork-child.c:132
        #4  0x00005606b50f14a5 in inf_ptrace_target::create_inferior
(this=0x5606bfccb2a0 <the_amd64_linux_nat_target>, exec_file=0x604000039f50
"/home/smarchi/build/binutils-gdb/gdb/test", allargs="", env=0x61500000a580,
from_tty=1)
            at /home/smarchi/src/binutils-gdb/gdb/inf-ptrace.c:105
        #5  0x00005606b53b6d23 in linux_nat_target::create_inferior
(this=0x5606bfccb2a0 <the_amd64_linux_nat_target>, exec_file=0x604000039f50
"/home/smarchi/build/binutils-gdb/gdb/test", allargs="", env=0x61500000a580,
from_tty=1)
            at /home/smarchi/src/binutils-gdb/gdb/linux-nat.c:978
        #6  0x00005606b512b79b in run_command_1 (args=0x0, from_tty=1,
run_how=RUN_NORMAL) at /home/smarchi/src/binutils-gdb/gdb/infcmd.c:468
        #7  0x00005606b512c236 in run_command (args=0x0, from_tty=1) at
/home/smarchi/src/binutils-gdb/gdb/infcmd.c:526

    When running the kill command, commit_resumed_state for the
    process_stratum_target (linux-nat, here) is true.  After the kill, when
    there are no more threads, commit_resumed_state is still true, as
    nothing touches this flag during the kill operation.  During the
    subsequent run command, run_command_1 does:

        scoped_disable_commit_resumed disable_commit_resumed ("running");

    We would think that this would clear the commit_resumed_state flag of
    our native target, but that's not the case, because
    scoped_disable_commit_resumed iterates on non-exited inferiors in order
    to find active process targets.  And after the kill, the inferior is
    exited, and the native target was unpushed from it anyway.  So
    scoped_disable_commit_resumed doesn't touch the commit_resumed_state
    flag of the native target, it stays true.  When reaching target_wait, in
    startup_inferior (to consume the initial expect stop events while the
    inferior is starting up and working its way through the shell),
    commit_resumed_state is true, breaking the contract saying that
    commit_resumed_state is always false when calling the targets' wait
    method.

    (note: to be correct, I think that startup_inferior should toggle
    commit_resumed between the target_wait and target_resume calls, but I'll
    ignore that for now)

    I can see multiple ways to fix this.  In the end, we need
    commit_resumed_state to be cleared by the time we get to that
    target_wait.  It could be done at the end of the kill command, or at the
    beginning of the run command.

    To keep things in a coherent state, I'd like to make it so that after
    the kill command, when the target is left with no threads, its
    commit_resumed_state flag is left to false.  This way, we can keep
    working with the assumption that a target with no threads (and therefore
    no running threads) has commit_resumed_state == false.

    Do this by adding a scoped_disable_commit_resumed in target_kill.  It
    clears the target's commit_resumed_state on entry, and leaves it false
    if the target does not have any resumed thread on exit.  That means,
    even if the target has another inferior with stopped threads,
    commit_resumed_state will be left to false, which makes sense.

    Add a test that tries to cover various combinations of actions done
    while an inferior is running (and therefore while commit_resumed_state
    is true on the process target).

    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28275
    Change-Id: I8e6fe6dc1f475055921520e58cab68024039a1e9
    Approved-By: Andrew Burgess <aburgess@redhat.com>

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