esp-idf
esp-idf copied to clipboard
esp_core_dump_get_summary returns the wrong cause of the exception (IDFGH-12775)
Answers checklist.
- [X] I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
- [X] I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
- [X] I have searched the issue tracker for a similar issue and not found a similar issue.
IDF version.
v5.2.1
Espressif SoC revision.
ESP32-S3 N16R2
Operating System used.
Windows
How did you build your project?
VS Code IDE
If you are using Windows, please specify command line type.
CMD
Development Kit.
Custom Board
Power Supply used.
Battery
What is the expected behavior?
I expected the ESP-IDF function esp_core_dump_get_summary
to fill the esp_core_dump_summary_t
struct with the summary of the core dump
What is the actual behavior?
Instead the ESP-IDF function esp_core_dump_get_summary
fills the esp_core_dump_summary_t
but the member esp_core_dump_summary_extra_info_t
has the wrong value of cause of exception
Steps to reproduce.
- Use
esp_core_dump_get_summary
to get a struct of the core sump summary - Print the member
ex_info.exc_cause
of the returned summary - Note that the value of
ex_info.exc_cause
does not correpond with theGuru Meditation Error
that prints when the exception occurs
Debug Logs.
Guru Meditation Error: Core 0 panic'ed (IntegerDivideByZero). Exception was unhandled.
Core 0 register dump:
PC : 0x4200197a PS : 0x00060330 A0 : 0x8037b273 A1 : 0x3fc9c710
A2 : 0x0000000a A3 : 0x3c025fbc A4 : 0x3c02603c A5 : 0x00000159
A6 : 0x3c025fbc A7 : 0x00000000 A8 : 0x00000000 A9 : 0x3fc9c6c0
A10 : 0x00000016 A11 : 0x3fc9c95c A12 : 0x00000000 A13 : 0x3fc97d9c
A14 : 0x3fc9dd5c A15 : 0x00000001 SAR : 0x0000001b EXCCAUSE: 0x00000006
EXCVADDR: 0x00000000 LBEG : 0x40056f5c LEND : 0x40056f72 LCOUNT : 0xffffffff
Backtrace: 0x42001977:0x3fc9c710 0x4037b270:0x3fc9c760 0x4037dfcd:0x3fc9c790
ELF file SHA256: e27b8295b
I (7896) esp_core_dump_flash: Save core dump to flash...
I (7902) esp_core_dump_flash: Erase flash 12288 bytes @ 0x510000
I (7998) esp_core_dump_flash: Write end offset 0x28e4, check sum length 4
I (7998) esp_core_dump_flash: Core dump has been saved to flash.
Rebooting...
ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0xc (RTC_SW_CPU_RST),boot:0x18 (SPI_FAST_FLASH_BOOT)
Saved PC:0x40376424
SPIWP:0xee
mode:DIO, clock div:1
load:0x3fce3810,len:0x178c
load:0x403c9700,len:0x4
load:0x403c9704,len:0xcc8
load:0x403cc700,len:0x2e68
entry 0x403c991c
I (31) boot: ESP-IDF 5.2.1 2nd stage bootloader
I (31) boot: compile time May 6 2024 12:18:20
I (31) boot: Multicore bootloader
I (34) boot: chip revision: v0.2
I (38) boot.esp32s3: Boot SPI Speed : 80MHz
I (43) boot.esp32s3: SPI Mode : DIO
I (48) boot.esp32s3: SPI Flash Size : 8MB
I (52) boot: Enabling RNG early entropy source...
I (58) boot: Partition Table:
I (61) boot: ## Label Usage Type ST Offset Length
I (69) boot: 0 nvs WiFi data 01 02 00009000 00006000
I (76) boot: 1 phy_init RF data 01 01 0000f000 00001000
I (84) boot: 2 factory factory app 00 00 00010000 00400000
I (91) boot: 3 littlefs Unknown data 01 82 00410000 00100000
I (98) boot: 4 coredump Unknown data 01 03 00510000 00010000
I (106) boot: End of partition table
I (110) esp_image: segment 0: paddr=00010020 vaddr=3c020020 size=0c34ch ( 49996) map
I (128) esp_image: segment 1: paddr=0001c374 vaddr=3fc93a00 size=03ca4h ( 15524) load
I (131) esp_image: segment 2: paddr=00020020 vaddr=42000020 size=1cee4h (118500) map
I (157) esp_image: segment 3: paddr=0003cf0c vaddr=3fc976a4 size=006d8h ( 1752) load
I (158) esp_image: segment 4: paddr=0003d5ec vaddr=40374000 size=0f9ach ( 63916) load
I (184) boot: Loaded app from partition at offset 0x10000
I (184) boot: Disabling RNG early entropy source...
I (195) cpu_start: Multicore app
I (206) cpu_start: Pro cpu start user code
I (206) cpu_start: cpu freq: 160000000 Hz
I (206) cpu_start: Application information:
I (209) cpu_start: Project name: FileSystemTests
I (214) cpu_start: App version: 1
I (219) cpu_start: Compile time: May 6 2024 12:13:31
I (225) cpu_start: ELF file SHA256: e27b8295b...
I (230) cpu_start: ESP-IDF: 5.2.1
I (235) cpu_start: Min chip rev: v0.0
I (240) cpu_start: Max chip rev: v0.99
I (245) cpu_start: Chip rev: v0.2
I (249) heap_init: Initializing. RAM available for dynamic allocation:
I (257) heap_init: At 3FC989F0 len 00050D20 (323 KiB): RAM
I (263) heap_init: At 3FCE9710 len 00005724 (21 KiB): RAM
I (269) heap_init: At 3FCF0000 len 00008000 (32 KiB): DRAM
I (275) heap_init: At 600FE010 len 00001FD8 (7 KiB): RTCRAM
I (282) spi_flash: detected chip: gd
I (285) spi_flash: flash io: dio
W (289) spi_flash: Detected size(16384k) larger than the size in the binary image header(8192k). Using the size in the binary image header.
I (303) sleep: Configure to isolate all GPIO pins in sleep state
I (310) sleep: Enable automatic switching of GPIO sleep configuration
I (316) esp_core_dump_flash: Init core dump to flash
I (322) esp_core_dump_flash: Found partition 'coredump' @ 510000 65536 bytes
I (342) esp_core_dump_flash: Core dump data checksum is correct
I (342) esp_core_dump_flash: Found core dump 10468 b▒tNow we are starting the Backtrace test ...
Reset reason: Software reset due to exception/panic
[exc_task] : main
[exc_cause]: 0
Illegal instruction
More Information.
I think the problem is with the implementation of the function elf_parse_version_info
inside of esp_core_dump_get_summary
in the \components\espcoredump\src\core_dump_elf.c
module
The function uses the following line to copy the value of the coredump that was stored in flash and in ELF format to the given struct
memcpy(summary->app_elf_sha256, version->app_elf_sha256, ELF_APP_SHA256_SIZE);
But the struct defines its member uint8_t app_elf_sha256[APP_ELF_SHA256_SZ];
with a size given by
#define APP_ELF_SHA256_SZ (CONFIG_APP_RETRIEVE_LEN_ELF_SHA + 1)
The size of ELF_APP_SHA256_SIZE
is set to 66 which can be bigger than APP_ELF_SHA256_SZ
which defaults to 9 and its calculated from the CONFIG_APP_RETRIEVE_LEN_ELF_SHA
given by the user in the menuconfig.
This causes that the memcpy to overflow into the esp_core_dump_summary_extra_info_t ex_info
member of the esp_core_dump_summary_t
struct
I fixed the problem by changing the memcpy line to the following
memcpy(summary->app_elf_sha256, version->app_elf_sha256, APP_ELF_SHA256_SZ);
and i had to add the following line to the file cause it doesn't have access to the APP_ELF_SHA256_SZ
definition
#define APP_ELF_SHA256_SZ (CONFIG_APP_RETRIEVE_LEN_ELF_SHA + 1)
I'm happy to provide a pull request with this change.
@m-scasserra Thanks for reporting the issue and possible solution. I can confirm, your analysis is correct. I will provide a fix soon.
@erhankur Thanks for the fast response! It's a small fix, do you want me to do the pull request?
@m-scasserra I already have an internal MR for the small fixes. I added this fix also. It will be merged after the review.