[Bug tui/30823] [gdb/tui] segfault in tui_find_disassembly_address

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

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

--- Comment #3 from cvs-commit at gcc dot gnu.org <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=72535eb14bda8ea61d801f007c4d38533c727832

commit 72535eb14bda8ea61d801f007c4d38533c727832
Author: Tom de Vries <tdevries@suse.de>
Date:   Thu Sep 28 20:17:33 2023 +0200

    [gdb/tui] Fix segfault in tui_find_disassembly_address

    PR29040 describes a FAIL for test-case
gdb.threads/next-fork-other-thread.exp
    and target board unix/-m32.

    The FAIL happens due to the test executable running into an assert, which
is
    caused by a forked child segfaulting, like so:
    ...
     Program terminated with signal SIGSEGV, Segmentation fault.
     #0  0x00000000 in ?? ()
    ...

    I tried to reproduce the segfault with exec next-fork-other-thread-fork,
using
    TUI layout asm.

    I set a breakpoint at fork and ran to the breakpoint, and somewhere during
the
    following session I ran into a gdb segfault here in
    tui_find_disassembly_address:
    ...
              /* Disassemble forward.  */
              next_addr = tui_disassemble (gdbarch, asm_lines, new_low,
max_lines);
              last_addr = asm_lines.back ().addr;
    ...
    due to asm_lines being empty after the call to tui_disassemble, while
    asm_lines.back () assumes that it's not empty.

    I have not been able to reproduce that segfault in that original setting,
I'm
    not sure of the exact scenario (though looking back it probably involved
    "set detach-on-fork off").

    What likely happened is that I managed to reproduce PR29040, and TUI
(attempted
    to) display the disassembly for address 0, which led to the gdb segfault.

    When gdb_print_insn encounters an insn it cannot print because it can't
read
    the memory, it throws a MEMORY_ERROR that is caught by tui_disassemble.

    The specific bit that causes the gdb segfault is that if gdb_print_insn
throws
    a MEMORY_ERROR for the first insn in tui_disassemble, it returns an empty
    asm_lines.

    FWIW, I did manage to reproduce the gdb segfault as follows:
    ...
    $ gdb -q \
        -iex "set pagination off" \
        /usr/bin/rustc \
        -ex "set breakpoint pending on" \
        -ex "b dl_main" \
        -ex run \
        -ex "up 4" \
        -ex "layout asm" \
        -ex "print \$pc"
      ...
    <TUI>
      ...
    $1 = (void (*)()) 0x1
    (gdb)
    ...
    Now press <up>, and the segfault triggers.

    Fix the segfault by handling asm_lines.empty () results of tui_disassemble
in
    tui_find_disassembly_address.

    I've written a unit test that exercises this scenario.

    Tested on x86_64-linux.

    Reviewed-by: Kevin Buettner <kevinb@redhat.com>

    PR tui/30823
    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30823

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