buserror
Segfault running my custom application on atmega16m1 core
I am a bit stuck on how to debug this issue. Tips and tricks are appreciated.
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7ef7e3d in avr_register_io_read (avr=avr@entry=0x555555563b00, addr=
It looks like the addr parameter into avr_register_io_read is 0. I recompiled with -O0, and here's a new backtrace:
#0 0x00007ffff7ef32ca in avr_register_io_read (avr=0x555555564b00, addr=0, readp=0x7ffff7efc258 <avr_uart_status_read>, param=0x5555555693a8) at sim/sim_io.c:64 #1 0x00007ffff7efd6a4 in avr_uart_init (avr=0x555555564b00, p=0x5555555693a8) at sim/avr_uart.c:545 #2 0x00007ffff7ef605d in avr_lin_init (avr=0x555555564b00, p=0x555555569348) at sim/avr_lin.c:101 #3 0x00007ffff7f0506d in mxm1_init (avr=0x555555564b00) at cores/sim_megaxm1.c:38 #4 0x00007ffff7ef46ab in avr_init (avr=0x555555564b00) at sim/sim_avr.c:120 #5 0x00005555555564a1 in main (argc=6, argv=0x7fffffffde38) at sim/run_avr.c:255
and: (gdb) p addr $1 = 0 (gdb) p a $2 = 65504
Did you figure anything out here? I'm struggling with this problem as well. In this line
if (avr->io[a].r.param || avr->io[a].r.c) {
in simavr/sim/sim_io.c it seems like whatever a is (I think the issue is in uart_init) is out of bounds of the array.
I'll double check the LIN register addresses in a bit.
@jack-greenberg: I had experienced crashes due to out-of-bounds access to the avr->io array. This was while simulating an ATmega2560, which has an “extended I/O” space larger than most AVRs, and larger than what simavr supports.
In my case, the issue was fixed by enlarging the array, as seen on PR #416. Would this help in your situation?
@edgar-bonet thanks for the suggestion! I did a bit more digging and determined the issue. The ATmega16m1 doesn't have a UART peripheral. The UART peripheral is combined with LIN, so the registers are used for many of the same things. Thus, when the UART init happens, some of the register addresses are zero, meaning they are converted to 0 - 0x20 in order to access memory, so this gives us a wrap-around large number. It seems like the way around is to somehow combine UART and LIN or else introduce some conditionals during init.
@buserror thoughts?
Ah, I now see that it is supported to have UART be part of the LIN peripheral.
It seems like the issue is the p->fe.reg in the uart_unit in line 536. This value is zero, so when it is passed to the register_read function, it is out of bounds of memory (0-0x20 results in a 16-but wrap-around).