espressif / esp-idf

Espressif IoT Development Framework. Official development framework for Espressif SoCs.
Apache License 2.0
13.67k stars 7.29k forks source link

Crash with Heap "Corruption Detection : Comprehensive" and "Default Log Level: Warning" (IDFGH-13515) #14406

Closed moefear85 closed 2 weeks ago

moefear85 commented 2 months ago

Answers checklist.

IDF version.

branch: release/v5.3 commit: 466a392

Espressif SoC revision.

esp32s2 v0.0

Operating System used.

Linux

How did you build your project?

VS Code IDE

If you are using Windows, please specify command line type.

None

Development Kit.

esp32-s2-wroom-I

Power Supply used.

External 3.3V

What is the expected behavior?

run without crashing

What is the actual behavior?

crashes upon boot

Steps to reproduce.

  1. Create a new empty template app
  2. In case it matters, set(COMPONENTS "main") in CMakeLists.txt
  3. In sdkconfig, set "heap corruption detection" to "comprehensive"
  4. set "default log level" to "warning"

Debug Logs.

ESP-ROM:esp32s2-rc4-20191025
Build:Oct 25 2019
rst:0x1 (POWERON),boot:0xa (SPI_FAST_FLASH_BOOT)
SPIWP:0xee
mode:DIO, clock div:1
load:0x3ffe5110,len:0x186c
load:0x4004a000,len:0x4
load:0x4004a004,len:0xb08
load:0x4004e000,len:0x3228
entry 0x4004a1cc
I (23) boot: ESP-IDF 466a392a 2nd stage bootloader
I (24) boot: compile time Aug 20 2024 22:18:01
I (24) boot: chip revision: v0.0
I (27) boot.esp32s2: SPI Speed      : 80MHz
I (32) boot.esp32s2: SPI Mode       : DIO
I (37) boot.esp32s2: SPI Flash Size : 2MB
I (42) boot: Enabling RNG early entropy source...
I (47) boot: Partition Table:
I (51) boot: ## Label            Usage          Type ST Offset   Length
I (58) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (65) boot:  1 phy_init         RF data          01 01 0000f000 00001000
I (73) boot:  2 factory          factory app      00 00 00010000 00100000
I (80) boot: End of partition table
I (84) esp_image: segment 0: paddr=00010020 vaddr=3f000020 size=069a8h ( 27048) map
I (98) esp_image: segment 1: paddr=000169d0 vaddr=3ffbf280 size=01a8ch (  6796) load
I (103) esp_image: segment 2: paddr=00018464 vaddr=40024000 size=07bb4h ( 31668) load
I (117) esp_image: segment 3: paddr=00020020 vaddr=40080020 size=115cch ( 71116) map
I (132) esp_image: segment 4: paddr=000315f4 vaddr=4002bbb4 size=036c8h ( 14024) load
I (142) boot: Loaded app from partition at offset 0x10000
I (142) boot: Disabling RNG early entropy source...
W (167) spi_flash: Detected size(4096k) larger than the size in the binary image header(2048k). Using the size in the binary image header.
Guru Meditation Error: Core  0 panic'ed (Unhandled debug exception). 
Debug exception reason: BREAK instr 
Core  0 register dump:
PC      : 0x400243c0  PS      : 0x00060e36  A0      : 0xfefefefe  A1      : 0x3fffe280  
0x400243c0: _DoubleExceptionVector at /media/STORAGE/source/esp-idf_release-v5.3_20.08.24/components/xtensa/xtensa_vectors.S:564

A2      : 0x00000001  A3      : 0x3f002398  A4      : 0x00001000  A5      : 0x00000000  
A6      : 0x3ffc2d14  A7      : 0x3ffc1d04  A8      : 0x00000000  A9      : 0x3ffc2d00  
A10     : 0x00000000  A11     : 0x00000000  A12     : 0x00000000  A13     : 0x3ffc2ce0  
A14     : 0x40090bf4  A15     : 0x00000000  SAR     : 0x00000000  EXCCAUSE: 0x00000001  
0x40090bf4: main_task at /media/STORAGE/source/esp-idf_release-v5.3_20.08.24/components/freertos/app_startup.c:159

EXCVADDR: 0xfefefede  LBEG    : 0x00000000  LEND    : 0x3ffc2ce0  LCOUNT  : 0x400270f3  
0x400270f3: _xt_panic at /media/STORAGE/source/esp-idf_release-v5.3_20.08.24/components/esp_system/port/arch/xtensa/panic_handler_asm.S:48

Backtrace: 0x400243bd:0x3fffe280 0x7efefefb:0x3ffc2c30 |<-CORRUPTED
0x400243bd: _UserExceptionVector at ??:?

ELF file SHA256: 725f1849a

CPU halted.

More Information.

yo long time no C (or esp-idf for that matter). this is a hobby project. what should have been 5 minutes cost me an entire afternoon to debug/pinpoint. It's 22:19 now. this reminds me why esp-idf can't be used for professional projects. If esp-idf never came to be, and espressif focused only on spi wifi modules, it would have saved me a lot of time as I would have jumped straight to stm32/nRF.

ESP-Marius commented 2 months ago

Sorry to hear that you are having a bad experience.

Seems like what is happening here is that a windowoverflow is trying to spill content to an invalid stack (the startup stack), causing an exception during spilling.

heap corruption detection" to "comprehensive" will write 0xFEFEFEFE to the startup stack when adding it to the heap which is what is causing the old start up stack values to no longer be valid.

And I guess with a higher logging level the window is spilled at an earlier stage while the start up stack is still safe, so that's why it only happens with this config combination.

We will take a look at it.

moefear85 commented 2 months ago

in case its relevant, i tried 12kb stacks for everything, even isrs. didnt help.

ESP-Marius commented 2 weeks ago

Should be fixed now with 4bf8d4915922d6f30911a7567cfbb5d3391f3473 merged