Replace addr2line with GDB to get accurate line #s #31
Conversation
An updated ESP8266 panic function can print out the calling function/line and size requested for the last malloc/realloc/calloc/new allocation that failed, without the overhead of full the OOM stack. Add parsing for this line, when present, and output the function, file, line, and amount of memory requested to the display. When not present, do nothing different.
src/EspExceptionDecoder.java
Outdated
| @@ -96,9 +97,34 @@ public String getMenuTitle() { | |||
| return "ESP Exception Decoder"; | |||
| } | |||
|
|
|||
| // Need custom one to redirect STDERR to STDOUT | |||
There was a problem hiding this comment.
It would be nice to add something like "Parts of the code are derived from Arduino project" near the top of the source file (the original file doesn't have an explicit copyright which we could keep).
There was a problem hiding this comment.
Added reference to where it came from in latest push.
|
@earlephilhower Since you have the EspExceptionDecoder open for surgery, may I ask you to add one more thing — printing out (and decoding) the program counter at the point of the exception ( |
|
You're actually getting this info already, just not nicely formatted. The existing decoder is very robust and tries to decode anything, anywhere, that looks like an address starting with 40XXXX. So the first line in "Decoding..." is normally the PC, followed by any other registers that have 40xxxx in them, then followed by addresses in the stack dump. Let me think a bit for a clean way to do this. Regexps could probably work, but are unwieldy and hard to maintain. A state machine (more brittle, though, than existing method) may be saner. |
|
Thanks, I didn't notice it also decoded the epc1. I think it would be valuable to print excvaddr, as its value sometimes tells more about the cause of the exception (helps distinguish between a null pointer dereference and garbage/corrupted memory, for instance). |
|
ESP8266 crash w/new commit, PC and EXEVADDR separated properly instead of looking like they're on the call stack: ESP32 crash (had to force this one!): |
earlephilhower
force-pushed
the
use_gdb
branch
from
564c43c to
8a7d6ff
Compare
earlephilhower
force-pushed
the
use_gdb
branch
from
8a7d6ff to
a84f9d6
Compare
Addr2line on the xtensa seems to have trouble with identifying the proper file:line number for an exception address. Until there is a fix, the workaround is to use GDB to locate them. See jcmvbkbc/binutils-gdb-xtensa#5 . Replace the addr2line processing/formatting with gdb's formatting, leaving the output identical with one exception: addresses with no source code (i.e. not code, but constant data somewhere or just random variables on the stack) *will not print*. They're silently ignored in the output. This also now presents the EPC1/PC and EXCVADDR on their own lines hilighted at the top of the dump. Additionally, handle the case where the exception dumper itself on the ESP8266 hits the WDT (i.e. during dump of an infinite recursion). In this case the final "<<<stack<<<" line may not be generated, so simply parse everything from ">>>stack>>>" to the end.
earlephilhower
force-pushed
the
use_gdb
branch
from
a84f9d6 to
a78672d
Compare
|
@me-no-dev Would you be able to take a look at this PR? We've just done a commit into the Arduino-ESP8266 repo which can be used with this new stack dump method to get better info on OOM errors (sadly very common even in the libs). It'll also help the ESP-32 since it works around the bugs in the Xtensa toolchain which don't seem to have a quick fix. |
|
Done :) Sorry for the delay! |
|
Thanks again! Hope it helps until the toolchain can be fixed... |
This works around issue #23 that @igrr and @me-no-dev reported where addr2line has issues on xtensa.
...snip...
Addr2line on the xtensa seems to have trouble with identifying the
proper file:line number for an exception address. Until there is a
fix, the workaround is to use GDB to locate them.
See jcmvbkbc/binutils-gdb-xtensa#5 .
Replace the addr2line processing/formatting with gdb's formatting,
leaving the output identical with one exception: addresses with
no source code (i.e. not code, but constant data somewhere or just
random variables on the stack) will not print. They're silently
ignored in the output.