Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: I'm currently working through the Rust Embedded tutorial with an STM32F3 Discovery board ( https://docs.rust-embedded.org/discovery/f3discovery/05-led-roulette/the-led-and-delay-abstractions.html ) I received the segfault during a debug session via OpenOCD and the onboard STLink. I run OpenOCD like this: $ openocd -f board/stm32f3discovery.cfg To start gdb I run this in a new terminal: $ cargo run Which translates to: gdb \ --directory=/home/niki/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/etc \ -iex add-auto-load-safe-path /home/niki/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/etc \ -q /home/niki/Sync/Projects/Software/discovery/f3discovery/target/thumbv7em-none-eabihf/debug/led-roulette In the gdb console I run these commands: target extended-remote :3333 layout split si si si .... <A lot of si commands> si si <Crash> If I start gdb, it crashes again: $ cargo run Finished dev [unoptimized + debuginfo] target(s) in 0.26s Running `rust-gdb -q /home/niki/Sync/Projects/Software/discovery/f3discovery/target/thumbv7em-none-eabihf/debug/led-roulette` Reading symbols from /home/niki/Sync/Projects/Software/discovery/f3discovery/target/thumbv7em-none-eabihf/debug/led-roulette... (gdb) target extended-remote :3333 Remote debugging using :3333 warning: Remote gdbserver does not support determining executable automatically. RHEL <=6.8 and <=7.2 versions of gdbserver do not support such automatic executable detection. The following versions of gdbserver support it: - Upstream version of gdbserver (unsupported) 7.10 or later - Red Hat Developer Toolset (DTS) version of gdbserver from DTS 4.0 or later (only on x86_64) - RHEL-7.3 versions of gdbserver (on any architecture) stm32f3_discovery::leds::Leds::new<stm32f3xx_hal::gpio::Input, stm32f3xx_hal::gpio::Input, stm32f3xx_hal::gpio::Input, stm32f3xx_hal::gpio::Input, stm32f3xx_hal::gpio::Input, stm32f3xx_hal::gpio::Input, stm32f3xx_hal::gpio::Input, stm32f3xx_hal::gpio::Input> (pe8=..., pe9=..., pe10=..., pe11=..., pe12=..., pe13=..., pe14=..., pe15=..., moder=0x20009f50, otyper=0x20009f50) at /home/niki/.cargo/registry/src/github.com-1ecc6299db9ec823/stm32f3-discovery-0.7.2/src/leds.rs:114 114 led.off().ok(); (gdb) layout split (gdb) si <Crash> Version-Release number of selected component: gdb-headless-12.1-6.fc37 Additional info: reporter: libreport-2.17.4 backtrace_rating: 4 cgroup: 0::/user.slice/user-1000.slice/user/app.slice/app-org.gnome.Terminal.slice/vte-spawn-241e9804-fef7-401a-862b-90167500c933.scope cmdline: gdb -q /home/niki/Sync/Projects/Software/discovery/f3discovery/target/thumbv7em-none-eabihf/debug/led-roulette crash_function: handle_fatal_signal executable: /usr/libexec/gdb journald_cursor: s=560923eb129142d29489cb50038b6c9c;i=1f5a4;b=7c458e252d0f4ecdaba2f4565cb48005;m=476fe872a2;t=5edd5885e2451;x=698c4ca0c857aee9 kernel: 6.0.8-300.fc37.x86_64 rootdir: / runlevel: N 5 type: CCpp uid: 1000
Created attachment 1925718 [details] File: backtrace
Created attachment 1925719 [details] File: core_backtrace
Created attachment 1925720 [details] File: cpuinfo
Created attachment 1925721 [details] File: dso_list
Created attachment 1925722 [details] File: environ
Created attachment 1925723 [details] File: limits
Created attachment 1925724 [details] File: maps
Created attachment 1925725 [details] File: mountinfo
Created attachment 1925726 [details] File: open_fds
Created attachment 1925727 [details] File: proc_pid_status
Created attachment 1925728 [details] File: led-roulette
If I don't turn on the split layout, I can run a single "si" and then enable the split layout and then continue. But when the loop reaches that point again, it crashes again. I tried to scroll around in the assembly pane, and when I come a little past the adress that PC is pointing at, then gdb crashes again, see attached picture, I guess that it is trying to disassemble something that it can't handle.
Created attachment 1925729 [details] Screenshot af ter crash
I can reproduce this on F37 (without needing a STM32F3 board) as follows: 1) Fetch / download led-roulette program from Comment 11. 2) Resize terminal to 214x50. This allows viewing of really wide assembly in TUI. (But it's probably also reproducible without being this wide.) 3) Start gdb via: gdb -q ./led-roulette 4) Enter the following GDB commands: x/i _ZN17stm32f3_discovery4leds4Leds3new17hf10206ffaebb0af3E layout asm 5) Scroll through assembly using the mouse wheel. For me, I get a SIGSEGV in GDB when 0x80007a8 is shown as the bottom-most address in the assembly window and I attempt to scroll past that point. If I attach to GDB with another GDB after step #3 (above) and then continue, at the SIGSEGV, I see: Thread 1 "gdb" received signal SIGSEGV, Segmentation fault. 0x0000561be69b9ee0 in mapping_symbol_for_insn (pc=pc@entry=134219622, info=info@entry=0x7fff79f3fdc8, map_symbol=map_symbol@entry=0x7fff79f3fcb8) at ../../opcodes/arm-dis.c:11868 11868 || bfd_asymbol_flavour (*info->symtab) != bfd_target_elf_flavour) (gdb) p/x info->symtab $1 = 0x0 (gdb) set height 0 (gdb) bt #0 0x0000561be69b9ee0 in mapping_symbol_for_insn (pc=pc@entry=134219622, info=info@entry=0x7fff79f3fdc8, map_symbol=map_symbol@entry=0x7fff79f3fcb8) at ../../opcodes/arm-dis.c:11868 #1 0x0000561be69beda9 in find_ifthen_state (little=true, info=0x7fff79f3fdc8, pc=134219626) at ../../opcodes/arm-dis.c:11743 #2 print_insn (pc=<optimized out>, info=<optimized out>, little=<optimized out>) at ../../opcodes/arm-dis.c:12284 #3 0x0000561be65e2d32 in gdb_disassembler::print_insn (this=0x7fff79f3fdc0, memaddr=134219626, branch_delay_insns=0x0) at ../../gdb/disasm.c:832 #4 0x0000561be65e384b in gdb_print_insn ( gdbarch=gdbarch@entry=0x561be81f49a0, memaddr=memaddr@entry=134219626, stream=stream@entry=0x7fff79f40000, branch_delay_insns=branch_delay_insns@entry=0x0) at ../../gdb/disasm.c:936 #5 0x0000561be692c1b2 in tui_disassemble (gdbarch=0x561be81f49a0, asm_lines=std::vector of length 0, capacity 0, pc=134219626, count=30, addr_size=0x7fff79f40130) at ../../gdb/tui/tui-disasm.c:120 #6 0x0000561be692d0a6 in tui_disasm_window::set_contents ( this=0x561be8357570, arch=<optimized out>, sal=...) at ../../gdb/tui/tui-disasm.c:343 #7 0x0000561be6946631 in tui_source_window_base::update_source_window_as_is ( this=0x561be8357570, gdbarch=<optimized out>, sal=...) at ../../gdb/tui/tui-winsource.c:167 #8 0x0000561be692cfbf in tui_disasm_window::do_scroll_vertical ( num_to_scroll=<optimized out>, this=0x561be8357570) at ../../gdb/tui/tui-disasm.c:459 #9 tui_disasm_window::do_scroll_vertical (this=0x561be8357570, num_to_scroll=<optimized out>) at ../../gdb/tui/tui-disasm.c:448 #10 0x0000561be6939bcc in tui_dispatch_mouse_event () at ../../gdb/tui/tui-io.c:977 #11 tui_getc_1 (fp=<optimized out>) at ../../gdb/tui/tui-io.c:1132 #12 tui_getc (fp=<optimized out>) at ../../gdb/tui/tui-io.c:1260 #13 0x00007f004ccf56ad in rl_read_key () at ../input.c:793 #14 0x00007f004ccd9712 in readline_internal_char () at ../readline.c:614 #15 0x00007f004ccf9205 in rl_callback_read_char () at ../callback.c:272 #16 0x0000561be665a70e in gdb_rl_callback_read_char_wrapper_noexcept () at ../../gdb/event-top.c:188 #17 0x0000561be665a8c4 in gdb_rl_callback_read_char_wrapper ( client_data=<optimized out>) at ../../gdb/event-top.c:205 #18 0x0000561be66596b8 in stdin_event_handler (error=<optimized out>, client_data=0x561be7ec1f10) at ../../gdb/event-top.c:527 #19 0x0000561be6b23156 in gdb_wait_for_event (block=block@entry=1) at ../../gdbsupport/event-loop.cc:725 #20 0x0000561be6b23717 in gdb_do_one_event () at ../../gdbsupport/event-loop.cc:237 #21 0x0000561be6733235 in start_event_loop () at ../../gdb/main.c:421 #22 captured_command_loop () at ../../gdb/main.c:481 #23 0x0000561be6735115 in captured_main (data=0x7fff79f40560) at ../../gdb/main.c:1351 #24 gdb_main (args=args@entry=0x7fff79f40590) at ../../gdb/main.c:1366 #25 0x0000561be6473e0e in main (argc=<optimized out>, argv=<optimized out>) at ../../gdb/gdb.c:40 I can't reproduce this problem by simply using (e.g.) 'x/1000i _ZN17stm32f3_discovery4leds4Leds3new17hf10206ffaebb0af3E' from (non-TUI) console mode. This might be fixed in upstream sources, though my upstream build has different problems: (gdb) x/i _ZN17stm32f3_discovery4leds4Leds3new17hf10206ffaebb0af3E No symbol '_ZN17stm32f3_discovery4leds4Leds3new17hf10206ffaebb0af3E' in current context Yet... (gdb) x/i 0x800061e 0x800061e <_ZN17stm32f3_discovery4leds4Leds3new17hf10206ffaebb0af3E>: push {r4, r5, r6, r7, lr} So it's able to print that minimal symbol as part the disassembly output, but does not recognize it when the user attempts to use it from the command line. That said, if I can figure out which commit which fixes the SIGSEGV, it's likely that I'll be able to backport it...
This is the upstream commit which fixes the SIGSEGV: commit 4eeb0013059856b8660b4a0351589b096167b4d1 Author: Alan Modra <amodra> Date: Fri Sep 30 10:26:30 2022 +0930 PR29626, Segfault when disassembling ARM code PR 29626 * arm-dis.c (mapping_symbol_for_insn): Return false on zero symtab_size. Delete later symtab_size test. opcodes/arm-dis.c | 124 +++++++++++++++++++++++++++--------------------------- 1 file changed, 61 insertions(+), 63 deletions(-) While I'm tempted to close it as being fixed upstream, I'm going to leave it open a while longer due to the problems that it demonstrates with upstream. See the end of Comment 14 where I show that doing x/i w/ a symbol fails to work, but using a numeric address does. This is definitely something that we want to fix in upstream so that it won't be broken in the next release.
Similar problem has been detected: Trying to get a backtrace from a core file. reporter: libreport-2.17.4 backtrace_rating: 4 cgroup: 0::/user.slice/user-1001.slice/user/app.slice/app-org.gnome.Terminal.slice/vte-spawn-8f5feaf6-46e9-45a1-8860-510a82458fa9.scope cmdline: gdb /usr/libexec/gnome-shell-calendar-server /var/spool/abrt/ccpp-2023-01-26-06:58:11.47887-386641/coredump crash_function: handle_fatal_signal executable: /usr/libexec/gdb journald_cursor: s=632e36554c744ddeaf7ead3675332496;i=5c8043;b=6c6c986c7204451a949dabefa2e3d5ec;m=44ede623cfe;t=5f329f27c3024;x=3b92e9c64664e5b6 kernel: 6.0.10-300.fc37.x86_64 package: gdb-headless-12.1-6.fc37 reason: gdb killed by SIGSEGV rootdir: / runlevel: N 5 type: CCpp uid: 1001
Closing this bug now... Regarding the problem noted in Comment 14, this is what I see now on F38 running GDB 13.1-4: (gdb) x/i 0x800061e 0x800061e <_ZN17stm32f3_discovery4leds4Leds3new17hf10206ffaebb0af3E>: push {r4, r5, r6, r7, lr} (gdb) x/i _ZN17stm32f3_discovery4leds4Leds3new17hf10206ffaebb0af3E 0x800061e <_ZN17stm32f3_discovery4leds4Leds3new17hf10206ffaebb0af3E>: push {r4, r5, r6, r7, lr} Before, using the symbol did not work for some reason. But it was fixed upstream and that fix made it into the GDB 13.1 rebase. I've also verified that the GDB no longer crashes when scrolling past address 0x80007a8 (with "layout asm") which was also described in Comment 14.