search

yubox-node-org / AsyncTCPSock

Reimplementation of the API of me-no-dev/AsyncTCP using high-level BSD sockets
GNU Lesser General Public License v3.0
20 stars 10 forks source link

Unhandled exception #1

Closed pletch closed 2 years ago

pletch commented 3 years ago

Testing this library to address WDT errors using ESPAsyncWebserver and AsyncTCP. No more WDT issues and works great so far but occasionally have this unhandled exception error:

`Guru Meditation Error: Core 1 panic'ed (LoadProhibited). Exception was unhandled. Core 1 register dump: PC : 0x40090e04 PS : 0x00060333 A0 : 0x8008ee64 A1 : 0x3ffe8120
A2 : 0x010037e4 A3 : 0xa8c0d833 A4 : 0x00000001 A5 : 0x00000001
A6 : 0x00060320 A7 : 0x00000000 A8 : 0x80090dfd A9 : 0x3ffe80f0 A10 : 0x00000002 A11 : 0x3ffe3a6c A12 : 0x00000001 A13 : 0x00000001
A14 : 0x00060323 A15 : 0x00000000 SAR : 0x0000000a EXCCAUSE: 0x0000001c
EXCVADDR: 0x010037f0 LBEG : 0x4000c2e0 LEND : 0x4000c2f6 LCOUNT : 0xffffffff

Backtrace: 0x40090e04:0x3ffe8120 0x4008ee61:0x3ffe8140 0x401b75e9:0x3ffe8180 0x401b76b6:0x3ffe81a0 0x401b77ce:0x3ffe81c0 0x40104c43:0x3ffe81e0 0x40104c51:0x3ffe8200 0x401b6c69:0x3ffe8220 0x401b7c69:0x3ffe8250 0x401b6ee3:0x3ffe8280 0x4008f0e5:0x3ffe82f0

0 0x40090e04:0x3ffe8120 in xTaskRemoveFromEventList at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/freertos/tasks.c:4813

1 0x4008ee61:0x3ffe8140 in xQueueGenericReceive at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/freertos/queue.c:1996

2 0x401b75e9:0x3ffe8180 in AsyncClient::_clearWriteQueue() at .pio\libdeps\d32_pro_tft\AsyncTCPSock\src/AsyncTCP.cpp:450

3 0x401b76b6:0x3ffe81a0 in AsyncClient::_close() at .pio\libdeps\d32_pro_tft\AsyncTCPSock\src/AsyncTCP.cpp:450

4 0x401b77ce:0x3ffe81c0 in AsyncClient::close(bool) at .pio\libdeps\d32_pro_tft\AsyncTCPSock\src/AsyncTCP.cpp:450

5 0x40104c43:0x3ffe81e0 in AsyncWebServerRequest::_onAck(unsigned int, unsigned int) at .pio\libdeps\d32_pro_tft\ESP Async WebServer\src/WebRequest.cpp:1021

6 0x40104c51:0x3ffe8200 in std::_Function_handler<void (void, AsyncClient, unsigned int, unsigned int), AsyncWebServerRequest::AsyncWebServerRequest(AsyncWebServer, AsyncClient)::{lambda(void, AsyncClient,

unsigned int, unsigned int)#5}>::_M_invoke(std::_Any_data const&, void&&, AsyncClient&&, unsigned int&&, AsyncClient*&&) at .pio\libdeps\d32_pro_tft\ESP Async WebServer\src/WebRequest.cpp:1021 (inlined by) _M_invoke at c:\users\tim.platformio\packages\toolchain-xtensa32\xtensa-esp32-elf\include\c++\5.2.0/functional:1871

7 0x401b6c69:0x3ffe8220 in std::function<void (void, AsyncClient, unsigned int, unsigned int)>::operator()(void, AsyncClient, unsigned int, unsigned int) const at .pio\libdeps\d32_pro_tft\AsyncTCPSock\src/AsyncTCP.cpp:450

8 0x401b7c69:0x3ffe8250 in AsyncClient::_sockIsWriteable() at .pio\libdeps\d32_pro_tft\AsyncTCPSock\src/AsyncTCP.cpp:450

9 0x401b6ee3:0x3ffe8280 in _asynctcpsock_task(void*) at .pio\libdeps\d32_pro_tft\AsyncTCPSock\src/AsyncTCP.cpp:450

10 0x4008f0e5:0x3ffe82f0 in vPortTaskWrapper at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/freertos/port.c:355 (discriminator 1)`

Any guidance on whether this is an implementation error on my side or does this associate with an underlying issue in the library?

avillacis commented 3 years ago

I have a strong suspicion there is a locking bug in my design that causes an use-after-free bug on the client mutex. I have a refactoring in mind that could help in that, but right now I am busy with my day-job (essentially make _socketBaseList an internal list-of-struct instead of a list-of-pointers, each struct holding the mutex and possibly the socket id). I have this refactoring on my todo-list, but suggestions are welcome.

What kind of network load caused this backtrace? Was it an ESPAsyncWebServer load, or some other kind? Was it a torture test, or just normal use on your project?

pletch commented 3 years ago

This occurred during ESPAsyncWebServer load and was just normal use. One of the webserver pages includes four concurrent jquery requests and it PANIC'd while hitting that page. Consequently, this same page very reliably triggers WDT timeouts with the standard AsyncTCP library.

avillacis commented 3 years ago

Just for a test, please test this branch of ESPAsyncWebServer I made from cleanups to a series of patches by @0xFEEDC0DE64 , along with my library:

yuboxfixes-0xFEEDC0DE64-cleanup

This will remove influence from all the concurrency and memory management bugs that @0xFEEDC0DE64 found and fixed, (hopefully) leaving whatever might be wrong with my code.

proddy commented 3 years ago

Really nice that you merged in sascha432's changes too. I've been using his build for a while now on all my projects and it's saved me about 15% of available heap space, which is critical on busy ESP8266s

avillacis commented 3 years ago

@pletch Please test the library up to at least commit https://github.com/yubox-node-org/AsyncTCPSock/commit/8ee20adb2bbc159a2e5155953fd455090eaf9fbf . I have been fixing a lot of bugs and one of them involves the client destructor racing with the connection processing by the asyncTcpSock task. This commit might just fix your issue.