[IDF5.0] abort() on core 1 doesn't lead to reboot (IDFGH-9183)

[ghost]

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.0

Operating System used.

Linux

How did you build your project?

Command line with idf.py

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

None

Development Kit.

Custom board, ESP32-S3

Power Supply used.

9V wall plug

What is the expected behavior?

Reboot when calling assert(false) or abort() on core 1.

What is the actual behavior?

Doesn't reboot. The last printed line is Rebooting... and then the board is stuck.

This only happens for aborts on core 1. On core 0 it works fine.

Steps to reproduce.

Note: This is tested using an ESP32-S3

• Create an example project for the ESP32-S3 with the standard settings
• Use the code from the "More Information" section
• Flash it and run it, observe the logs

Debug Logs.

I (91) cpu_start: Pro cpu start user code
I (91) cpu_start: cpu freq: 160000000 Hz
I (91) cpu_start: Application information:
I (94) cpu_start: Project name:     foo
I (98) cpu_start: App version:      1
I (102) cpu_start: Compile time:     Jan 19 2023 12:57:05
I (109) cpu_start: ELF file SHA256:  0997ddcfa6d99dd4...
I (114) cpu_start: ESP-IDF:          v5.0
I (120) heap_init: Initializing. RAM available for dynamic allocation:
I (127) heap_init: At 3FC94480 len 00055290 (340 KiB): D/IRAM
I (133) heap_init: At 3FCE9710 len 00005724 (21 KiB): STACK/DRAM
I (140) heap_init: At 3FCF0000 len 00008000 (32 KiB): DRAM
I (146) heap_init: At 600FE010 len 00001FF0 (7 KiB): RTCRAM
I (153) spi_flash: detected chip: gd
I (157) spi_flash: flash io: dio
I (161) cpu_start: Starting scheduler on PRO CPU.
I (0) cpu_start: Starting scheduler on APP CPU.

abort() was called at PC 0x42007937 on core 1
0x42007937: taskFn at /home/marcel/abort-bug-minimal-sample-proj/main/foo.c:8



Backtrace: 0x40375cd2:0x3fceac20 0x40379b69:0x3fceac40 0x4037f02a:0x3fceac60 0x42007937:0x3fceacd0 0x4037c4fd:0x3fceacf0
0x40375cd2: panic_abort at /opt/esp/idf/components/esp_system/panic.c:412

0x40379b69: esp_system_abort at /opt/esp/idf/components/esp_system/esp_system.c:142

0x4037f02a: abort at /opt/esp/idf/components/newlib/abort.c:38

0x42007937: taskFn at /home/marcel/abort-bug-minimal-sample-proj/main/foo.c:8

0x4037c4fd: vPortTaskWrapper at /opt/esp/idf/components/freertos/FreeRTOS-Kernel/portable/xtensa/port.c:151





ELF file SHA256: 0997ddcfa6d99dd4

Rebooting...

More Information.

A minimal example:

#include "freertos/FreeRTOS.h"
#include "freertos/task.h"

#include <stdio.h>

void taskFn(void* foo) {
    vTaskDelay(pdMS_TO_TICKS(2500));
    abort();
    while(1) {

    }
}

void app_main(void)
{
    TaskHandle_t xHandle = NULL;
    xTaskCreatePinnedToCore(taskFn, "MyTask", 4096, NULL, tskIDLE_PRIORITY, &xHandle, 1);
}

[mahavirj]

This was reported in #10320 and fixed through c280d4b

[ghost]

That's good news. Feel free to close this bug as duplicate.

Any plan on when a release containing the fix will be available?

[mahavirj]

Any plan on when a release containing the fix will be available?

Release v5.0.1 is under internal QA, hopefully it will be published in next few weeks.