Guru Meditation Error: Core 0 panic'ed (Store access fault). Exception was unhandled. (IDFGH-10033) #11310
Comments
aggaddam
changed the title
github-actions
bot
changed the title
|
These kind of errors from the heap component are usually caused by memory corruption, some suggestions:
If you are able to provide a minimal example which I could run to reproduce this issue? |
|
@ESP-Marius Here is the sample code you can use to replicate the problem. You should see this https server response
|
|
@aggaddam |
|
I am getting chunk len from evt->data_len. I am just printing the value of esp_http_client_get_content_length(evt->client) which is -1 in the case of chunk data transfer mode. |
|
espressif-bot
added
Status: In Progress
|
@mahavirj I tried with native example code as well but the same issue is happening with example code as well. I just replaced the URL for image download SDK config and associated certificate. After downloading few chunks of data device is crashing assert msg heap mem fail. The same error was observed with our project application as well Here is the log |
|
@aggaddam Can you please share the patch that you created on top of native_ota_example? |
|
@mahavirj Attached source code file. (Remove .txt extension after you downloaded the file) |
|
@mahavirj Did you get a chance to look into this issue? Are you able to recreate it? |
|
Hello @aggaddam |
|
@hmalpani Have you tried with esp-idf version from branch release/v5.1 ? |
|
@aggaddam |
|
@hmalpani |
|
@hmalpani Could you please share the commit of idf v5.1 used for testing ? I will try with the same commit id. |
|
@hmalpani I got the same assert error after receiving a few chunks of data. Here is the server configuration that I received while fetching headers. Hope it will be useful |
|
Hi @aggaddam are you still concerned about this problem? tslf assert usually occurs when a pointer oversteps one byte. I am very interested in debugging this problem. Could you please send me a demo that can reproduce the problem |
|
Hello @aggaddam |
|
@Jacques-Zhao @hmalpani Attached is the log for your reference and the native ota example code used. ota_example_https_chunk_data_log.txt |
|
@Jacques-Zhao Are you able to recreate the problem that I mentioned? |
|
@aggaddam I'm sorry that I can't repeat the problem you mentioned, but I was dealing with a similar problem last week, and I haven't found the root cause yet, but there is a workaround you can try. Just disable hardware AES acceleration(MBEDTLS_HARDWARE_AES) in the menuconfig. Please test with this configuration item and let me know the results. |
|
Hello @aggaddam |
|
@hmalpani Here is the SDK config file |
|
@aggaddam Have you tested the method I'm talking about? I have found the root cause of this problem, if you disable AES hardware acceleration can fix the problem, you can try to modiy lldesc_setup_link_constrained change |
|
Just to extend on the @Jacques-Zhao comment, please try following patch and see if it can help to fix your issue: |
|
Hello @aggaddam |
|
@hmalpani I didn't get a chance to test this out this week. I will test this change next week and let you know the feedback. |
|
HI, i also got this error when downloading the bin file using HHTPS. My network test environment is a Chinese network, connected to an Amazon server in Europe, and downloaded 128K bin files 13 times in a row using HTTPS GET. Then this error happens sporadically, here is the error log: |
After applying this fix, a new error appeared, the log is as follows: |
My test method is to use HTTPS GET to download the bin file (128K bytes * 13) multiple times in a row. It seems that "Just disable hardware AES acceleration (MBEDTLS_HARDWARE_AES)" can solve my problem ( assert failed: remove_free_block tlsf.c:330 (prev && "prev_free field can not be null") ). The conclusion of this test is for reference. Thanks. |
|
Your change in #11310 (comment) is different from #11310 (comment). I'm not sure which one is correct. i.e. The diff would be below if apply both changes. |
|
The version of the patch I had posted in my comment was correct. I am also attaching the full version of the fix here which includes a test case that can easily recreate the failure aes_fix_for_DMA_descriptors_calculations.tar.gz Command to apply the patch:
Can you please share your application, sdkconfig and other details? It is quite possible that your issue is entirely different than one reported here, maybe you can file a new issue and share all details. |
Confirm the patch fixes the panic on ESP32C3. |
espressif-bot
added
Status: Done
The number of the DMA descriptors allocated for certain length (e.g., 8176) were not sufficient (off by 1 error). This used to result in the dynamic memory corruption as the region was modified beyond the allocated range. This change fixes the DMA descriptor calculation part and allocates sufficient DMA descriptors based on the data length alignment considerations. Test has also been added to cover the specific scenario in the CI. Closes #11310
The number of the DMA descriptors allocated for certain length (e.g., 8176) were not sufficient (off by 1 error). This used to result in the dynamic memory corruption as the region was modified beyond the allocated range. This change fixes the DMA descriptor calculation part and allocates sufficient DMA descriptors based on the data length alignment considerations. Test has also been added to cover the specific scenario in the CI. Closes #11310
The number of the DMA descriptors allocated for certain length (e.g., 8176) were not sufficient (off by 1 error). This used to result in the dynamic memory corruption as the region was modified beyond the allocated range. This change fixes the DMA descriptor calculation part and allocates sufficient DMA descriptors based on the data length alignment considerations. Test has also been added to cover the specific scenario in the CI. Closes #11310
|
@mahavirj I applied the patch in esp32c3 target, and now the device is not crashing while downloading the image from the https server but there is still a problem while downloading the image from the HTTPS server with chunked transfer encoded data. The issue is after downloading a few packets, I am not seeing a callback event for HTTP_EVENT_ON_DATA and finally ended up receiving partial data instead of full data I tried with the native ota example and HTTP streaming example. Same behavior observed Attached log file for your reference Do you want me to open a new issue for the download issue with https or can we track the issue here? |
The number of the DMA descriptors allocated for certain length (e.g., 8176) were not sufficient (off by 1 error). This used to result in the dynamic memory corruption as the region was modified beyond the allocated range. This change fixes the DMA descriptor calculation part and allocates sufficient DMA descriptors based on the data length alignment considerations. Test has also been added to cover the specific scenario in the CI. Closes #11310
|
Is this a security vulnerability? |
Answers checklist.
IDF version.
release/v5.1
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.
ESP32C3-DEVKIT
Power Supply used.
USB
What is the expected behavior?
I am getting crash with esp IDF v5.1
Guru Meditation Error: Core 0 panic'ed (Store access fault). Exception was unhandledwhile downloading firmware binary from https server having chunked transfer encoded data.This issue was not observed with v4.x.x idf version
What is the actual behavior?
The crash should not happen during firmware image binary download from server
Steps to reproduce.
Download the firmware ota image binary from any https server with chunked transfer encoded data.
Debug Logs.
More Information.
Here is the backtrace after analysis PC address 0x40389b4e
No response
The text was updated successfully, but these errors were encountered: