Closed mphe closed 2 months ago
As always, 30 minutes later I realize I'm dumb. It apparently is indeed a memory issue. Memory is running low and the right combination of build settings bumps the usage up just far enough to make allocation unreliable. Depending on where I put my log statements, it fails at another point.
Answers checklist.
IDF version.
master, 5.2.2, 5.2.1
Espressif SoC revision.
ESP32-S3-WROOM-2-N32R8V
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.
ESP32-S3-DevKitC-1
Power Supply used.
USB
What is the expected behavior?
malloc
calls succeed as long as there is sufficient memory with the requested capabilities, regardless of build settings.What is the actual behavior?
heap_caps_calloc
fails to allocate memory ("Mem alloc fail") even though enough memory should be available, but only in certain situations and when a certain combination of build settings is enabled.While working on a project with
esp-matter
I suddenly encountered crashes due to memory allocation fails after changing some build settings usingidf.py menuconfig
. WithoutCONFIG_HEAP_ABORT_WHEN_ALLOCATION_FAILS=y
, the program will not crash immediately but still cause errors and possibly crash at a later point due to access to uninitialized data/subsystems.Steps to reproduce.
export.sh
esp-matter/examples/controller
idf.py set-target esp32s3
sdkconfig
to the project.idf.py (erase-flash) flash monitor
and observe the program crashing at the "chip[IN]: CASE Server enabling CASE session setups" stepI was unable to reproduce a failing malloc on my own but the
controller
example ofesp-matter
works as a MRP. During client initialization, a call toheap_caps_calloc
invoked by mbedTLS will fail. See also the included crash log. There could also be more places where these settings lead to failing mallocs besides mbedTLS.I tried to strip down the changes in
sdkconfig
to a minimum and found the following build settings to reliably reproduce the error. It is possible that there are also other combinations that cause the same issue.Besides these settings the
controller
example is unchanged.I included a patch file containing the diffs between the default
sdkconfig
and the failing version, as well as the whole failingsdkconfig
. The patch file also includes other changes that were made automatically by the build system upon changing certain settings, e.g. enabling PSRAM.sdkconfig_diff.txt sdkconfig.txt
Debug Logs.
More Information.
I'm not sure if this is an IDF,
esp-matter
or CHIP related bug, but I think it belongs here as it only involves IDF build settings and occurs in IDF code.