I've got an odd crasher I'm trying to debug that lands me in _DoubleExceptionVector
(gdb) bt
#0 _DoubleExceptionVector () at /Users/.../esp/esp-idf/components/freertos/port/xtensa/xtensa_vectors.S:461
#1 0x40377288 in _xt_lowint1 () at /Users/.../esp/esp-idf/components/freertos/port/xtensa/xtensa_vectors.S:1096
Sometimes it says the stack is corrupted. In this case it just thinks that's the entire stack. I tried tweaking SP and PC, but things like
set $pc=...
just get ignored. I'd love some helpful hints on why pc and sp changes in GDB are ignoring me, any hints on recovering the stack trace, and/or other ways to debug this. I can now reproduce this crash in a few seconds, so it's easy for me to tweak and try again.
I'm using esp-2021r2-patch5-8.4.0 for gdb and v0.11.0-esp32-20220706 for openocd.
Recovering stack trace
Re: Recovering stack trace
Looks like the level 1 interrupt entry code is hitting a bad stack pointer (_xt_lowint1), thus why it's jumping a double exception vector. When the stack pointer itself is corrupted, there isn't really a way to recover the rest of the stack due to xtensa's windowed ABI (previous stack frame's stack pointer is supposed to be saved under the current stack pointer). Thus if the current stack pointer is corrupted, that information won't be there.
We might be able to recover some information from the other registers though. Could you post a copy of the register dump when the double exception is triggered?
We might be able to recover some information from the other registers though. Could you post a copy of the register dump when the double exception is triggered?
Who is online
Users browsing this forum: Bing [Bot] and 128 guests