Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Segfault running my custom application on atmega16m1 core #335

Open
edgargrimberg opened this issue Apr 8, 2019 · 5 comments
Open

Segfault running my custom application on atmega16m1 core #335

edgargrimberg opened this issue Apr 8, 2019 · 5 comments

Comments

@edgargrimberg
Copy link

edgargrimberg commented Apr 8, 2019

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=, readp=readp@entry=0x7ffff7efdfd0 <avr_uart_status_read>, param=param@entry=0x5555555683a8) at sim/sim_io.c:64
(gdb) bt
#0 0x00007ffff7ef7e3d in avr_register_io_read (avr=avr@entry=0x555555563b00, addr=, readp=readp@entry=0x7ffff7efdfd0 <avr_uart_status_read>, param=param@entry=0x5555555683a8) at sim/sim_io.c:64
#1 0x00007ffff7eff8df in avr_uart_init (avr=avr@entry=0x555555563b00, p=p@entry=0x5555555683a8) at sim/avr_uart.c:545
#2 0x00007ffff7ef9a95 in avr_lin_init (avr=avr@entry=0x555555563b00, p=p@entry=0x555555568348) at sim/avr_lin.c:101
#3 0x00007ffff7f04978 in mxm1_init (avr=0x555555563b00) at cores/sim_megaxm1.c:38
#4 0x00007ffff7ef8c70 in avr_init (avr=0x555555563b00) at sim/sim_avr.c:120
#5 0x0000555555555445 in main (argc=4, argv=0x7fffffffde58) at sim/run_avr.c:255

@edgargrimberg
Copy link
Author

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

@jack-greenberg
Copy link
Contributor

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.

@edgar-bonet
Copy link

@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?

@jack-greenberg
Copy link
Contributor

@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?

@jack-greenberg
Copy link
Contributor

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants