Watchdog timer triggered when serving large files from SPIFFS #825
Description
I've reduced my code to the absolute minimum:
void setupWebServer() {
// Initialize SPIFFS
if(!SPIFFS.begin(true)) {
// ... logging and stuff...
return;
}
// Start WiFi. Connect to, or become, an AP
if (!setupWiFi())
return;
server.serveStatic("/", SPIFFS, "/").setDefaultFile("status.html");
server.onNotFound([](AsyncWebServerRequest *request){request->send(404);});
server.begin();
}
The application is dependent upon jQuery, Bootstrap, ion.rangeSlider and popper. Initially my pages were loading online copies,
but because my device must be accessible offline I took to serving minimized local copies from the ESP, and that's when the problems started. So my pages include:
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no">
<link rel="stylesheet" href="/css/bootstrap.min.css">
<link rel="stylesheet" href="/css/ion.rangeSlider.min.css">
<link rel="stylesheet" href="/css/styles.css">
<script src="/js/jquery-3.4.1.slim.min.js"></script>
<script src="/js/popper.min.js"></script>
<script src="/js/bootstrap.min.js"></script>
<script src="/js/ion.rangeSlider.min.js"></script>
<script src="/js/shared.js"></script>
<script src="/js/configure.js"></script>
Often the first one or two page loads succeed, but then the ESP resets; although it isn't strictly reproducible.
The error message isn't particularly useful as the backtrace is of the watchdog mechanism rather than of the task that didn't reset the watchdog:
E (107592) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time:
E (107592) task_wdt: - async_tcp (CPU 1)
E (107592) task_wdt: Tasks currently running:
E (107592) task_wdt: CPU 0: IDLE0
E (107592) task_wdt: CPU 1: IDLE1
E (107592) task_wdt: Aborting.
abort() was called at PC 0x400edcef on core 0
Backtrace: 0x4008c434:0x3ffbe170 0x4008c665:0x3ffbe190 0x400edcef:0x3ffbe1b0 0x40084771:0x3ffbe1d0 0x40186a5f:0x3ffbc280 0x400ef0da:0x3ffbc2a0 0x4008a361:0x3ffbc2c0 0x40088b7d:0x3ffbc2e0
#0 0x4008c434:0x3ffbe170 in invoke_abort at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/esp32/panic.c:707
#1 0x4008c665:0x3ffbe190 in abort at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/esp32/panic.c:707
#2 0x400edcef:0x3ffbe1b0 in task_wdt_isr at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/esp32/task_wdt.c:252
#3 0x40084771:0x3ffbe1d0 in _xt_lowint1 at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/freertos/xtensa_vectors.S:1154
#4 0x40186a5f:0x3ffbc280 in esp_pm_impl_waiti at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/esp32/pm_esp32.c:492
#5 0x400ef0da:0x3ffbc2a0 in esp_vApplicationIdleHook at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/esp32/freertos_hooks.c:108
#6 0x4008a361:0x3ffbc2c0 in prvIdleTask at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/freertos/tasks.c:3507
#7 0x40088b7d:0x3ffbc2e0 in vPortTaskWrapper at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/freertos/port.c:355 (discriminator 1)
Rebooting...
I see several similar issues logged in the past, but all slightly different and none with a resolution (excepting using the non-async web server instead, which I'd rather not do). I do notice that if I serve up one HUGE file rather than several large files the system appears stable.
Is there anything I can do before investigating JTAG debugging as a means to determine what async_tcp is doing?