ESP_LOGX functions crash after writing to SPIFFS

[try_except]

Hi guys,
I'm using SPIFFS to save some photos captured by my ESP32-CAM. This works without issues the first time, but after this, every call to ESP_LOGX (no matter if it's ESP_LOGI, ESP_LOGV, etc.) crashes with LoadProhibited. I have a task running on core 1 that gets the frame from the OV2640 sensor and sends it via a FreeRTOS queue to a task on core 0. This second task receives the buffer, opens a file using an std::ofstream object, writes to it, flushes it and closes it before waiting for the next buffer to be received, but after the first one it always crashes the same way:

Code: Select all

Guru Meditation Error: Core  0 panic'ed (LoadProhibited). Exception was unhandled.

Core  0 register dump:
PC      : 0x400d90ac  PS      : 0x00060230  A0      : 0x80088d2c  A1      : 0x3ffb76c0  
--- 0x400d90ac: esp_vfs_write at C:/Users/simon/esp/v5.4.1/esp-idf/components/vfs/vfs.c:945

A2      : 0x3ffb7ef0  A3      : 0x00000009  A4      : 0x3ffaed68  A5      : 0x00000045  
A6      : 0x3ffb7b20  A7      : 0x3ffaecb0  A8      : 0x3f8bc0cc  A9      : 0x8a8988ed  
A10     : 0x00000000  A11     : 0x00000000  A12     : 0x00060e20  A13     : 0x00060e23  
A14     : 0x3ffb0128  A15     : 0x3ffaecb0  SAR     : 0x00000004  EXCCAUSE: 0x0000001c  
EXCVADDR: 0x8a8988ed  LBEG    : 0x40089c89  LEND    : 0x40089c99  LCOUNT  : 0xfffffffc  
--- 0x40089c89: strlen at /builds/idf/crosstool-NG/.build/xtensa-esp-elf/src/newlib/newlib/libc/machine/xtensa/strlen.S:84
--- 0x40089c99: strlen at /builds/idf/crosstool-NG/.build/xtensa-esp-elf/src/newlib/newlib/libc/machine/xtensa/strlen.S:96



Backtrace: 0x400d90a9:0x3ffb76c0 0x40088d29:0x3ffb76e0 0x40088055:0x3ffb7700 0x400880aa:0x3ffb7720 0x400885c5:0x3ffb7740 0x40128337:0x3ffb7770 0x40127d3e:0x3ffb7790 0x40118cd9:0x3ffb7ab0 0x40135e7d:0x3ffb7ae0 0x40090459:0x3ffb7b10 0x400dd4af:0x3ffb7b60 0x4008c26e:0x3ffb7e10
--- 0x400d90a9: esp_vfs_write at C:/Users/simon/esp/v5.4.1/esp-idf/components/vfs/vfs.c:942
--- 0x40088d29: __swrite at /builds/idf/crosstool-NG/.build/xtensa-esp-elf/src/newlib/newlib/libc/stdio/stdio.c:94
--- 0x40088055: __sflush_r at /builds/idf/crosstool-NG/.build/xtensa-esp-elf/src/newlib/newlib/libc/stdio/fflush.c:224
--- 0x400880aa: _fflush_r at /builds/idf/crosstool-NG/.build/xtensa-esp-elf/src/newlib/newlib/libc/stdio/fflush.c:278
--- 0x400885c5: __sfvwrite_r at /builds/idf/crosstool-NG/.build/xtensa-esp-elf/src/newlib/newlib/libc/stdio/fvwrite.c:251
--- 0x40128337: __sprint_r at /builds/idf/crosstool-NG/.build/xtensa-esp-elf/src/newlib/newlib/libc/stdio/vfprintf.c:429
---  (inlined by) __sprint_r at /builds/idf/crosstool-NG/.build/xtensa-esp-elf/src/newlib/newlib/libc/stdio/vfprintf.c:399
--- 0x40127d3e: _vfprintf_r at /builds/idf/crosstool-NG/.build/xtensa-esp-elf/src/newlib/newlib/libc/stdio/vfprintf.c:1774 (discriminator 1)
--- 0x40118cd9: vprintf at /builds/idf/crosstool-NG/.build/xtensa-esp-elf/src/newlib/newlib/libc/stdio/vprintf.c:34
--- 0x40135e7d: esp_log_writev at C:/Users/simon/esp/v5.4.1/esp-idf/components/log/src/os/log_write.c:34
--- 0x40090459: esp_log_write at C:/Users/simon/esp/v5.4.1/esp-idf/components/log/src/os/log_write.c:44
--- 0x400dd4af: spiffs::StorageManager::grab_frame(void*) at E:/GitRepos/CapstoneCAM/components/camera_controller/src/storage_manager.cpp:163 (discriminator 1)
--- 0x4008c26e: vPortTaskWrapper at C:/Users/simon/esp/v5.4.1/esp-idf/components/freertos/FreeRTOS-Kernel/portable/xtensa/port.c:139

The code at line 163 of storage_manager.cpp is simply

Code: Select all

ESP_LOGV(TAG, "Notification received");

And the task stack size is way bigger than the default (8192), so the usual suspects were already ruled out.

Any help would be greatly appreciated

[adokitkat]

Hello. Could you please share more of your code where the ESP_LOGX is used in? Or even better a reproducible code example, if it is possible? Please also share your ESP-IDF version and chip you are using. Thank you.

[try_except]

I'm terribly sorry, I finally solved the issue and it was (obviously) my own damn fault but forgot to delete this post. I had a FreeRTOS queue with a bigger item size than the amount of data in the buffer I was sending. This resulted in memory corruption and finally in the error I was encountering. Lesson learned.

[adokitkat]

Thanks for clarifying and I am glad you fixed your issue! But please don't remove your post since it may help someone in the future in a similar situation.