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

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

[vries at gcc dot gnu.org]

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

            Bug ID: 30823
           Summary: [gdb/tui] segfault in tui_find_disassembly_address
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: tui
          Assignee: unassigned at sourceware dot org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

I was walking through
outputs/gdb.threads/next-fork-other-thread/next-fork-other-thread-fork (build
with target board unix/-m32), using TUI layout asm, first setting a breakpoint
at fork and the running, then doing nexti a lot when hitting the breakpoints in
the various threads.

I ran into a segfault:
...
(gdb) bt
#0  0x00007fe36c6ad76b in raise () from /lib64/libpthread.so.0
#1  0x000000000078ed99 in handle_fatal_signal (sig=11) at
/data/vries/gdb/src/gdb/event-top.c:912
#2  0x000000000078ee21 in handle_sigsegv (sig=11) at
/data/vries/gdb/src/gdb/event-top.c:962
#3  <signal handler called>
#4  0x0000000000c5e7a4 in tui_find_disassembly_address (gdbarch=0x45110a0,
pc=4158011920, from=-6)
    at /data/vries/gdb/src/gdb/tui/tui-disasm.c:247
#5  0x0000000000c5f0c3 in tui_get_low_disassembly_address (gdbarch=0x45110a0,
low=4158011920, 
    pc=4158011920) at /data/vries/gdb/src/gdb/tui/tui-disasm.c:439
#6  0x0000000000c5f32e in tui_disasm_window::maybe_update (this=0x42ecdb0,
fi=..., sal=...)
    at /data/vries/gdb/src/gdb/tui/tui-disasm.c:500
#7  0x0000000000c7fc83 in tui_show_frame_info (fi=...)
    at /data/vries/gdb/src/gdb/tui/tui-stack.c:284
#8  0x0000000000c6140f in tui_refresh_frame_and_register_information ()
    at /data/vries/gdb/src/gdb/tui/tui-hooks.c:136
#9  0x0000000000c61618 in tui_before_prompt (
    current_gdb_prompt=0x293ced0 <top_prompt+16> "(gdb) ")
    at /data/vries/gdb/src/gdb/tui/tui-hooks.c:185
#10 0x0000000000797fa5 in std::_Function_handler<void (char const*), void
(*)(char const*)>::_M_invoke(std::_Any_data const&, char const*&&)
(__functor=..., 
    __args#0=@0x7fffc6b93e00: 0x293ced0 <top_prompt+16> "(gdb) ")
    at /usr/include/c++/7/bits/std_function.h:316
#11 0x000000000078fcc1 in std::function<void (char const*)>::operator()(char
const*) const (
    this=0x4950e10, __args#0=0x293ced0 <top_prompt+16> "(gdb) ")
    at /usr/include/c++/7/bits/std_function.h:706
#12 0x000000000078fa96 in gdb::observers::observable<char const*>::notify (
    this=0x2938560 <gdb::observers::before_prompt>, args#0=0x293ced0
<top_prompt+16> "(gdb) ")
    at /data/vries/gdb/src/gdb/../gdbsupport/observable.h:166
#13 0x000000000078e20d in top_level_prompt () at
/data/vries/gdb/src/gdb/event-top.c:474
#14 0x000000000078e110 in display_gdb_prompt (new_prompt=0x0)
    at /data/vries/gdb/src/gdb/event-top.c:441
#15 0x00000000005fe6c8 in cli_interp_base::on_sync_execution_done
(this=0x43ddfc0)
    at /data/vries/gdb/src/gdb/cli/cli-interp.c:149
#16 0x000000000085cb32 in check_curr_ui_sync_execution_done ()
    at /data/vries/gdb/src/gdb/infrun.c:4285
#17 0x000000000085cb6e in all_uis_check_sync_execution_done ()
    at /data/vries/gdb/src/gdb/infrun.c:4297
#18 0x000000000085d334 in fetch_inferior_event () at
/data/vries/gdb/src/gdb/infrun.c:4563
#19 0x000000000083ace6 in inferior_event_handler (event_type=INF_REG_EVENT)
    at /data/vries/gdb/src/gdb/inf-loop.c:42
#20 0x000000000086b136 in infrun_async_inferior_event_handler (data=0x0)
    at /data/vries/gdb/src/gdb/infrun.c:9836
#21 0x000000000052ad74 in check_async_event_handlers ()
    at /data/vries/gdb/src/gdb/async-event.c:338
#22 0x000000000149b938 in gdb_do_one_event (mstimeout=-1)
    at /data/vries/gdb/src/gdbsupport/event-loop.cc:221
#23 0x00000000008f5d37 in start_event_loop () at
/data/vries/gdb/src/gdb/main.c:412
#24 0x00000000008f5e91 in captured_command_loop () at
/data/vries/gdb/src/gdb/main.c:476
#25 0x00000000008f767d in captured_main (data=0x7fffc6b94540)
    at /data/vries/gdb/src/gdb/main.c:1320
#26 0x00000000008f7717 in gdb_main (args=0x7fffc6b94540) at
/data/vries/gdb/src/gdb/main.c:1339
#27 0x0000000000415f53 in main (argc=10, argv=0x7fffc6b94658) at
/data/vries/gdb/src/gdb/gdb.c:39
(gdb) 
...

The problem seems to be here:
...
(gdb) down
#4  0x0000000000c5e7a4 in tui_find_disassembly_address (gdbarch=0x45110a0,
pc=4158011920, from=-6)
    at /data/vries/gdb/src/gdb/tui/tui-disasm.c:247
247               last_addr = asm_lines.back ().addr;
(gdb) p asm_lines.back ()
You can't do that without a process to debug.
(gdb) p asm_lines
$3 = {<std::_Vector_base<tui_asm_line, std::allocator<tui_asm_line> >> = {
    _M_impl = {<std::allocator<tui_asm_line>> =
{<__gnu_cxx::new_allocator<tui_asm_line>> = {<No data fields>}, <No data
fields>}, _M_start = 0x0, _M_finish = 0x0, 
      _M_end_of_storage = 0x0}}, <No data fields>}
...

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

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

[vries at gcc dot gnu.org]

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

--- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> ---
With some inspiration from PR27593, I managed to reproduce.

Start gdb with rustc binary:
...
$ 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.

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

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

[vries at gcc dot gnu.org]

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

--- Comment #2 from Tom de Vries <vries at gcc dot gnu.org> ---
https://sourceware.org/pipermail/gdb-patches/2023-September/202157.html

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

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

[cvs-commit at gcc dot gnu.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.

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

[vries at gcc dot gnu.org]

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

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |14.1

--- Comment #4 from Tom de Vries <vries at gcc dot gnu.org> ---
Fixed.

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

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

[vries at gcc dot gnu.org]

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

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #5 from Tom de Vries <vries at gcc dot gnu.org> ---
And ... fixed.

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