esp_execute_shared_stack_function: random Watchpoint 1 panics without CONFIG_FREERTOS_WATCHPOINT_END_OF_STACK (IDFGH-9003) #10414
Labels
Resolution: Done
Issue is done internally
Status: Done
Issue is done internally
Type: Bug
bugs in IDF
Answers checklist.
IDF version.
v5.0-378-g5278cc7de0
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.
LILYGO T-Embed ESP32-S3
Power Supply used.
USB
What is the expected behavior?
The program continues to work after calling
esp_execute_shared_stack_function
What is the actual behavior?
Random panics:
usually from malloc code, but randomly from other places too.
Steps to reproduce.
esp_execute_shared_stack_function
(just with a noop function)Debug Logs.
No response
More Information.
Here it sets the watchpoint to the shared stack:
esp-idf/components/esp_system/port/arch/xtensa/expression_with_stack.c
Lines 46 to 48 in 5278cc7
And it resets here after returning:
esp-idf/components/esp_system/port/arch/xtensa/expression_with_stack.c
Line 78 in 5278cc7
Please not that there is no
#if CONFIG_FREERTOS_WATCHPOINT_END_OF_STACK
here. And without that config, normally nothing sets watchpoint 1, which means if later anything accesses that memory (for example because the task was deleted and its memory was reused for something else), it will panic. Adding that missing#if
seems to fix the problem.Also here it sets
pxDummy6
(akapxStack
) to the shared stack's beginning, shouldn't it also setpxEndOfStack
?esp-idf/components/esp_system/port/arch/xtensa/expression_with_stack.c
Line 39 in 5278cc7
From a quick look, it looks like riscv implementation has the same problem, but I never tried to use that.
The text was updated successfully, but these errors were encountered: