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>} ...
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.
https://sourceware.org/pipermail/gdb-patches/2023-September/202157.html
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
Fixed.
And ... fixed.