ESP8266 Crashing During Prints randomly #9069
Comments
|
Hi Experts, Now we have commented particular printf as reported in previous message and decoded stack and run it again. Now every time we are seeing stack smashing every time as below but with exception decoder unable to figure out problem. Can you please help us where to look in to code. Decoded exception does not show any code written by us, its all SDK code Stack smashing detected.
Exception (5):
epc1=0x40100553 epc2=0x00000000 epc3=0x00000000 excvaddr=0x00000000 depc=0x00000000
>>>stack>>>
ctx: sys
sp: 3ffffe80 end: 3fffffb0 offset: 0000
3ffffe80: 3fffdad0 00000000 3fff1810 40100553
3ffffe90: 3fffdad0 00000000 3fff1810 4021e09b
3ffffea0: feefeffe feefeffe 3fffdab0 40100529
3ffffeb0: feefeffe 3fffee90 00000278 3ffffed0
3ffffec0: 4010fda5 00000004 00000008 4010feae
3ffffed0: 00000000 00000000 00000000 9a000000
3ffffee0: 00000000 400042db 3ffeada0 00000001
3ffffef0: 00000000 401000c0 00000001 401000b8
3fffff00: 00001000 60000200 3fffffb0 3ffffe30
3fffff10: 00000278 00000000 00064320 40100000
3fffff20: 00002780 5ffffe00 00000000 00ff0000
3fffff30: 401006a9 000003fc 00000000 3ffffec2
3fffff40: 400203e9 40100438 ffffff00 ffffe6fc
3fffff50: ffffffff 3fffff70 00000004 4000177a
3fffff60: 00ff0000 383d373d 343e363e 00000000
3fffff70: 00000000 003c1d0d 003c003c 003c007c
3fffff80: 0f03090f 070f0307 03070f03 fe85130c
3fffff90: 4a4e800e 383c4046 0702fdfa 02fe0e0b
3fffffa0: 12100c07 100a0502 05021613 1613100a
<<<stack<<<
Exception 5: Alloca: MOVSP instruction, if caller's registers are not in the register file
PC: 0x40100553: cont_check(cont_t*) at C:\Users\vipin\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\3.1.2\cores\esp8266\cont_util.cpp:56
EXCVADDR: 0x00000000
Decoding stack results
0x40100553: cont_check(cont_t*) at C:\Users\vipin\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\3.1.2\cores\esp8266\cont_util.cpp:56
0x4021e09b: loop_wrapper() at C:\Users\vipin\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\3.1.2\cores\esp8266\core_esp8266_main.cpp:260
0x401000c0: app_entry() at C:\Users\vipin\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\3.1.2\cores\esp8266\core_esp8266_main.cpp:392
0x401000b8: app_entry_redefinable() at C:\Users\vipin\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\3.1.2\cores\esp8266\core_esp8266_main.cpp:386
0x401006a9: uart_write_char_d(char) at C:\Users\vipin\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\3.1.2\cores\esp8266\core_esp8266_postmortem.cpp:310 |
|
^ dump above just means crash had happened, same as 'Exception' line is used to fit into existing crash format. At that point stack is already rolled back and we are calling One way to guard against stack usage is to enable 'stack protection' option from the IDE menu, which would force the stack check after every function call instead of just after user task suspends (yield(), delay(), esp_suspend(), esp_yield()). This way crash would happen while inside of some function, not within our While that is enabled, you could also amend build flags with edit: Either by creating SKETCH_NAME.ino.globals.h in the root of the sketch folder /*@create-file:build.opt@
-Wstack-usage=512
*/Or, editing build flags for board stack protector option. For generic.menu.stacksmash.enabled.build.stacksmash_flags=-fstack-protectorgeneric.menu.stacksmash.enabled.build.stacksmash_flags=-fstack-protector -Wstack-usage=512I would also suggest going lower even to possibly catch some nested calls causing stack to grow too much. Note that build log size would greatly increase. Maybe related to #8666 |
- check in cont_run() and cont_suspend() whether a1 is out of bounds - in case a1 is broken, postmortem will still report proper context in proper stack boundaries additionally - as suggested in esp8266#9069, change stack smashing to a single line that does not mention any Exceptions - reduce overall stack dump length when there are know garbage values i.e. cont stackguard - decoder.py addr search regexp would no longer skip stack lines with '<' - fix decoder.py parsing so it notices both stack smashing and alloc errors
- check in cont_run() and cont_suspend() whether a1 is out of bounds - in case a1 is broken, postmortem will still report proper context in proper stack boundaries additionally - as suggested in #9069, change stack smashing to a single line that does not mention any Exceptions - reduce overall stack dump length when there are know garbage values i.e. cont stackguard - decoder.py addr search regexp would no longer skip stack lines with '<' - fix decoder.py parsing so it notices both stack smashing and alloc errors
Basic Infos
Platform
Settings in IDE
Problem Description
We have implemented IOT device. It works stable without any issue if we disable debug prints that we are printing using
Serial.printf(). However When we enable printing It it crashes randmonly once out of around 5 -7 messages. With printing disabled it did not crash even once with 500 messages sent in loop.We have checked the print statement, arguments but do not see anything wrong. For example we have below print statement
Not sure if it is crashing on this print, but we tried to decode exception using plugin https://github.com/dankeboy36/esp-exception-decoder/actions and here are the exception and decoded details that seems to be pointing to DevNVStore.cpp:1115. Provided above is the print statement on this line. Entire code is too big to be shared.
Below is exception and its decoding
Can someone please help? Is it stack smashing? If yes how could such simple print can cause stack to be corrupted?
Do you see any issue in Serial.printf implementation in core?
Debug messages go here
The text was updated successfully, but these errors were encountered: