esp_core_dump_get_summary returns the wrong cause of the exception (IDFGH-12775)

[m-scasserra]

Answers checklist.

• I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
• I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
• 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.

1. Use esp_core_dump_get_summary to get a struct of the core sump summary
2. Print the member ex_info.exc_cause of the returned summary
3. Note that the value of ex_info.exc_cause does not correpond with the Guru 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.

[erhankur]

@m-scasserra Thanks for reporting the issue and possible solution. I can confirm, your analysis is correct. I will provide a fix soon.

[m-scasserra]

@erhankur Thanks for the fast response! It's a small fix, do you want me to do the pull request?

[erhankur]

@m-scasserra I already have an internal MR for the small fixes. I added this fix also. It will be merged after the review.