Libwebsockets with FatFS

[teckhaokoh]

I've successfully run HTTPS server using libwebsockets with esp-idf release v4.2.

Everything worked well, until I tried accesing FatFs in the esp32.... Either read or write even fseek will cause it calling abort and reboot...

Any idea or possible causes of the problem?

[ESP_Sprite]

Hard to say. Do you have a backtrace of one of those abort+reboots? Can you post a minimal example that exhibits this behaviour?

[teckhaokoh]

Hi, thanks for your response, here's the backtrace:

0x4009547e: panic_abort at /home/user/esp/esp-4.2/esp-idf/components/esp_system/panic.c:330
0x40095185: esp_system_abort at /home/user/esp/esp-4.2/esp-idf/components/esp_system/system_api.c:97
0x400980f6: abort at /home/user/esp/esp-4.2/esp-idf/components/newlib/abort.c:46
0x40084c7a: lock_acquire_generic at /home/user/esp/esp-4.2/esp-idf/components/newlib/locks.c:142
0x40084db1: _lock_acquire_recursive at /home/user/esp/esp-4.2/esp-idf/components/newlib/locks.c:170
0x4010813a: _vfiprintf_r at /builds/idf/crosstool-NG/.build/xtensa-esp32-elf/src/newlib/newlib/libc/stdio/vfprintf.c:853 (discriminator 1)
0x400fee7b: fiprintf at /builds/idf/crosstool-NG/.build/xtensa-esp32-elf/src/newlib/newlib/libc/stdio/fiprintf.c:484
0x400feb82: __assert_func at /builds/idf/crosstool-NG/.build/xtensa-esp32-elf/src/newlib/newlib/libc/stdlib/assert.c:58 (discriminator 8)
0x40091e9b: get_next_block at /home/user/esp/esp-4.2/esp-idf/components/heap/multi_heap.c:131
(inlined by) multi_heap_get_info_impl at /home/user/esp/esp-4.2/esp-idf/components/heap/multi_heap.c:790
0x400916dd: multi_heap_get_info at /home/user/esp/esp-4.2/esp-idf/components/heap/multi_heap_poisoning.c:376
0x400d8e6f: heap_caps_get_info at /home/user/esp/esp-4.2/esp-idf/components/heap/heap_caps.c:415
0x400d8ec1: heap_caps_get_largest_free_block at /home/user/esp/esp-4.2/esp-idf/components/heap/heap_caps.c:403
0x40085777: esp_flash_read at /home/user/esp/esp-4.2/esp-idf/components/spi_flash/esp_flash_api.c:513
0x4011e031: esp_partition_read at /home/user/esp/esp-4.2/esp-idf/components/spi_flash/partition.c:347
0x401b8f3a: Partition::read(unsigned int, void*, unsigned int) at /home/user/esp/esp-4.2/esp-idf/components/wear_levelling/Partition.cpp:56
0x401b8e6b: WL_Flash::read(unsigned int, void*, unsigned int) at /home/user/esp/esp-4.2/esp-idf/components/wear_levelling/WL_Flash.cpp:611
0x401b7943: wl_read at /home/user/esp/esp-4.2/esp-idf/components/wear_levelling/wear_levelling.cpp:223
0x4015f233: ff_wl_read at /home/user/esp/esp-4.2/esp-idf/components/fatfs/diskio/diskio_wl.c:46
0x4015f159: ff_disk_read at /home/user/esp/esp-4.2/esp-idf/components/fatfs/diskio/diskio.c:70
0x4015e306: f_lseek at /home/user/esp/esp-4.2/esp-idf/components/fatfs/src/ff.c:4399
0x4015ba7b: vfs_fat_lseek at /home/user/esp/esp-4.2/esp-idf/components/fatfs/vfs/vfs_fat.c:495
0x4011f563: esp_vfs_lseek at /home/user/esp/esp-4.2/esp-idf/components/vfs/vfs.c:433 (discriminator 3)
0x4008f8a9: memcmp at /builds/idf/crosstool-NG/.build/xtensa-esp32-elf/src/newlib/newlib/libc/string/memcmp.c:49
0x400ff5e1: _fseeko_r at /builds/idf/crosstool-NG/.build/xtensa-esp32-elf/src/newlib/newlib/libc/stdio/fseeko.c:334
0x400ff2ca: _fseek_r at /builds/idf/crosstool-NG/.build/xtensa-esp32-elf/src/newlib/newlib/libc/stdio/fseek.c:89
(inlined by) fseek at /builds/idf/crosstool-NG/.build/xtensa-esp32-elf/src/newlib/newlib/libc/stdio/fseek.c:99
0x400eab80: do_serve_dashboard_home at /mnt/hgfs/vmshared/ft04/main/web/dashboard/lwsdashboard_handler.c:489



lwsdashboard_handler.c:489 this is my own code, which actually calling fseek(file);

from the backtrace, the abort() part is actually acquire the lock.
Anything you can suggest that I may doing it wrongly?

Some background on what I'm trying to do
I'm using the wrover-i module, with 16MB flash + 4MB/8MB SPIRAM, using FatFS file system.
I'm actually have the HTTP server running using esp_http_server.
I'm now trying to upgrade it to HTTPS server.
I did tried the esp_https_server, it's running but keep getting mbedtls handshake error -30592 and seems to keep recreating connection and performing handshake, thus make the webpage loading very slow, can go up to 40s-50s (of course, it's a big web page serving dashbaord page with a lot of css files and js files).

Then I give it a try to build the HTTPS server using libwebsockets to compare the performance, since I'll need the libwebsockets in future for other features. This is where I encounter this issue. I'm using the same codes to access the same file in esp_http_server & esp_https_server but never have this abort()+reboot issue.

[ESP_Sprite]

Smells like memory corruption (assert in the heap allocator) that then tries to panic but can't properly, likely because of the aforementioned memory corruption.

[teckhaokoh]

Smells like memory corruption (assert in the heap allocator) that then tries to panic but can't properly, likely because of the aforementioned memory corruption.

Thanks for verify that.
That memory corruption means some memory leak and not properly free right?

It always failed when accessing the file, does that means the memory corruption happened during the file access?
Or it can be anywhere?

[ESP_Sprite]

No, memory corruption means that you e.g. allocate a buffer for 16 bytes and then write 17 bytes into it, or free a buffer and then still write into it. Memory corruption is a bit tricky in that it's not noticed until the corrupted memory is actually used, so your problem doesn't need to be in the file access stuff.

[teckhaokoh]

Understood.
Thank you very much for your info.
I'll review my code and focus on the issues as you mentioned.