[Bug gdb/33069] After failed inferior call, gdb receives SIGTTOU and suspends

[cvs-commit at gcc dot gnu.org]

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

--- Comment #1 from Sourceware Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tom de Vries <vries@sourceware.org>:

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

commit 77060dcf0db3e4d63c7b5d6341db2453328d5edc
Author: Tom de Vries <tdevries@suse.de>
Date:   Mon Sep 1 09:07:11 2025 +0200

    [gdb] Fix handling of aborted inferior call

    PR gdb/33069 reports the following behavior:
    ...
    $ gdb -q ls -ex starti -ex "b *1"
    Reading symbols from ls...
    (No debugging symbols found in ls)
    Starting program: /usr/bin/ls

    Program stopped.
    0x00007ffff7fe4f00 in _start () from /lib64/ld-linux-x86-64.so.2
    Breakpoint 1 at 0x1
    (gdb) p (int)strlen("abc")
    Warning:
    Cannot insert breakpoint 1.
    Cannot access memory at address 0x1

    Command aborted.
    An error occurred while in a function called from GDB.
    Evaluation of the expression containing the function
    (malloc@plt) will be abandoned.
    When the function is done executing, GDB will silently stop.

    [1]+  Stopped                 gdb -q ls -ex starti -ex "b *1"
    $ fg
    gdb -q ls -ex starti -ex "b *1"
    (gdb)
    ...
    with gdb being unresponsive to further input.

    PR gdb/33068 reports a similar problem, but using gdbserver, and in that
case
    gdb doesn't go into the background, but is likewise unresponsive.

    This is a regression since commit b1c0ab20809 ("gdb: avoid double stop
after
    failed breakpoint condition check"), and consequently since release gdb
14.1.

    The commit changed this in run_inferior_call:
    ...
       if (current_ui->prompt_state == PROMPT_BLOCKED)
    -    current_ui->unregister_file_handler ();
    -  else
    -    current_ui->register_file_handler ();
    +    {
    +      if (call_thread->thread_fsm ()->finished_p ())
    +       async_disable_stdin ();
    +      else
    +       async_enable_stdin ();
    +    }
    ...
    which means current_ui->register_file_handler is no longer called in the
    current_ui->prompt_state == PROMPT_NEEDED case.

    Fix this by:
    - restoring this behavior, fixing the unresponsiveness, and
    - adding target_terminal::ours alongside it, fixing the problem that gdb
goes
      into the background.

    Add a new test-case gdb.base/infcall-failure-2.exp, a regression test for
the
    unresponsiveness issue.  The problem of gdb going into the background did
not
    reproduce in the test-case.

    Tested on x86_64-linux.

    Reviewed-By: Keith Seitz <keiths@redhat.com>

    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33068
    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33069

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