Voltron causing gdb to crash when views launched with tmuxp/tmuxinator/screen
bitshiftnetau opened this issue · comments
System: Arch Linux
Kernel: 4.19.91-1-lts
Debugger: arm-none-eabi-gdb
openocd.cfg:
source [find /usr/share/openocd/scripts/interface/jlink.cfg]
jlink serial XXXXXXXXX
transport select swd
adapter_khz 1000
set CHIPNAME efm32
gdb_flash_program enable
gdb_memory_map enable
gdb_report_data_abort enable
source [find /usr/share/openocd/scripts/target/efm32.cfg]
.gdbinit:
target remote localhost:3333
monitor reset halt
monitor resume
load /srv/code/c/spongecake/build/release/spongecake.axf
symbol-file /srv/code/c/spongecake/build/release/spongecake.axf
source /usr/lib/python3.8/site-packages/voltron/entry.py
.tmuxp.yaml:
session_name: 4-pane-split
windows:
- window_name: dev window
layout: tiled
shell_command_before:
- cd ~/ # run as a first command in all panes
panes:
- arm-none-eabi-gdb --command=/srv/code/c/spongecake/tools/gdb/.gdbinit
- voltron view disasm
- voltron view reg
- voltron view stack
- voltron view bp
If I run:
tmux load .
It loads up the panes, then drops a connection error (because voltron isn't loaded yet), then gdb sources the entry point for voltron and then does one of a two things:
- connects and displays a view
- seg faults
What's very strange, is that I can't reliably reproduce this fault by eliminating certain views with one exception: when it is one pane with gdb and one pane with voltron. Other than that, it randomly segfaults with 2 or all of the views and also randomly works with 1 or all of the views. I know this has to be a voltron+screen(or tmux)+gdb issue because opening voltron views in independent terminals works just fine, no problems at all but adding that muxer breaks everything.
Same issue with either tmuxinator, tmuxp, or screen.
RAM is also not even close to being full and virtual memory has been expanded to 'infinite'.
Any suggestions?
Output from
'strace arm-none-eabi-gdb'
Output produced after opening 4 voltron views with tmuxp. Also tried adding sleep commands to each pane and they seem to fail less. However, it obviously still fails when the debugger stops and voltron re-syncs the views simultaneously. Dunno if that helps.
read(3, 0x7fff78bfef37, 1) = -1 EAGAIN (Resource temporarily unavailable)
futex(0x7f7ed8002f50, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f7ef5b3496c, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f7ef5b34970, FUTEX_WAKE_PRIVATE, 1) = 1
read(7, 0x7fff78bff027, 1) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=3, events=POLLIN}, {fd=7, events=POLLIN}, {fd=11, events=POLLIN}, {fd=0, events=POLLIN}], 4, 0) = 0 (Timeout)
poll([{fd=3, events=POLLIN}, {fd=7, events=POLLIN}, {fd=11, events=POLLIN}, {fd=0, events=POLLIN}], 4, -1) = 1 ([{fd=3, revents=POLLIN}])
rt_sigaction(SIGINT, {sa_handler=0x556ef424ae00, sa_mask=[INT], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f7ef520efb0}, {sa_handler=0x556ef424ae00, sa_mask=[INT], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f7ef520efb0}, 8) = 0
read(3, "+", 1) = 1
read(3, 0x7fff78bfef37, 1) = -1 EAGAIN (Resource temporarily unavailable)
futex(0x7f7ed8005e90, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f7ef5b34968, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f7ef5b34970, FUTEX_WAKE_PRIVATE, 1) = 1
read(7, 0x7fff78bff027, 1) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=3, events=POLLIN}, {fd=7, events=POLLIN}, {fd=11, events=POLLIN}, {fd=0, events=POLLIN}], 4, 0) = 0 (Timeout)
poll([{fd=3, events=POLLIN}, {fd=7, events=POLLIN}, {fd=11, events=POLLIN}, {fd=0, events=POLLIN}], 4, -1) = 1 ([{fd=3, revents=POLLIN}])
rt_sigaction(SIGINT, {sa_handler=0x556ef424ae00, sa_mask=[INT], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f7ef520efb0}, {sa_handler=0x556ef424ae00, sa_mask=[INT], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f7ef520efb0}, 8) = 0
futex(0x7f7ef5b3496c, FUTEX_WAIT_BITSET_PRIVATE, 0, {tv_sec=15609, tv_nsec=36997690}, FUTEX_BITSET_MATCH_ANY) = 0
futex(0x7f7ef5b34970, FUTEX_WAKE_PRIVATE, 1) = 0
read(3, "+", 1) = 1
read(3, 0x7fff78bfef37, 1) = -1 EAGAIN (Resource temporarily unavailable)
getpid() = 590492
futex(0x7f7ed0004220, FUTEX_WAKE_PRIVATE, 1) = 1
getpid() = 590492
getpid() = 590492
getpid() = 590492
getpid() = 590492
futex(0x7f7ef5b34968, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f7ef5b34970, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f7ef5b3496c, FUTEX_WAIT_BITSET_PRIVATE, 0, {tv_sec=15609, tv_nsec=37369392}, FUTEX_BITSET_MATCH_ANY) = -1 EAGAIN (Resource temporarily unavailable)
futex(0x7f7ef5b34970, FUTEX_WAKE_PRIVATE, 1) = 0
getpid() = 590492
futex(0x7f7ef5b34968, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f7ef5b34970, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f7ef5b3496c, FUTEX_WAIT_BITSET_PRIVATE, 0, {tv_sec=15609, tv_nsec=37499929}, FUTEX_BITSET_MATCH_ANY) = 0
futex(0x7f7ef5b34970, FUTEX_WAKE_PRIVATE, 1) = 0
getpid() = 590492
futex(0x7f7ef5b34968, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f7ef5b34970, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f7ef5b3496c, FUTEX_WAIT_BITSET_PRIVATE, 0, {tv_sec=15609, tv_nsec=37909343}, FUTEX_BITSET_MATCH_ANY) = 0
futex(0x7f7ef5b34970, FUTEX_WAKE_PRIVATE, 1) = 0
getpid() = 590492
getpid() = 590492
getpid() = 590492
getpid() = 590492
getpid() = 590492
getpid() = 590492
getpid() = 590492
getpid() = 590492
getpid() = 590492
getpid() = 590492
getpid() = 590492
getpid() = 590492
getpid() = 590492
getpid() = 590492
getpid() = 590492
futex(0x7f7ee4004cf0, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f7ef5b34968, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f7ef5b34970, FUTEX_WAKE_PRIVATE, 1) = 1
--- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=NULL} ---
+++ killed by SIGSEGV (core dumped) +++
Segmentation fault (core dumped)
NEVERMIND: I did a silly!! Was using different versions of arm toolchain across compilation and debugging. Was using 7.2_2017q4 for compiling and 9.2 for debugging doii!!
I've redirected to using the appropriate gdb and now the only problem is that the views simply don't load at all.
I'll open another issue for that.