ESP8266 crash when spamming/sending 8/16/32... etc long commands via WebSerial console

[serpinio]

First of all - love WebSerial, it's extremely useful!

I did stumble upon a very nasty bug, wonder if it's just me or it's a legit one: I accidentally discovered that if you send a command via WebSerial input and the command is 8 or 16 or 32 chars in length, this sometimes completely crashes the microcontroller and causes it to reboot. To replicate:

1. Use ESP2866 (mine is NodeCMU ESP12E)
2. Open example "Demo" from the WebSerial package
3. Configure WiFi credentials and compile
4. Open WebSerial in the browser
5. Try spamming any of these into the input field and pressing Enter:

12345678 (8 chars) 1234567812345678 (16 chars)

At some point the console will stop responding and the microcontroller crashes and reboots. After a reboot the same command can be sent several times and it will crash ESP8266 over and over again.

This only happens with 8/16 etc-long commands. Any idea why?

[serpinio]

To make it easier to catch the bug, try a string with different characters including a space bar. See demo attached. Sometimes you don't even need to spam the command, it can crash the chip on a first-third try. Again — only happens with 8/16 etc-long commands.

To further increase the chance of the controller crashing try loading it up with some tasks: connect it to WiFi, let it count some numbers in a loop e.t.c., in my real sketch it takes just 2-3 of 8 charlong calls to crash the controller. And regardless of how much I span it with non 8/16 char-long commands, it never ever crashes.

https://user-images.githubusercontent.com/82693390/161275308-0f979563-bf5d-4306-a8ce-c4caed64f4c8.mp4

[ayushsharma82]

Tested and it's not related to character length but instead related to the usage of Strings inside WebSerial, sending a lot of commands quickly overflows the buffer inside the AsyncWebSocket library. Try the same thing without writing back to WebSerial immediately, it should work.

Till then I'll see if we can mitigate this issue by having a fixed buffer inside the WebSerial library.

Here's the exception which I got:

Exception 3: LoadStoreError: Processor internal physical address or data error during load or store
PC: 0x40106686
EXCVADDR: 0x4000f754

Decoding stack results
0x4020298e: AsyncWebSocket::_cleanBuffers() at D:\Arduino\libraries\ESPAsyncWebServer\src/StringArray.h line 53
0x40100847: umm_free_core(umm_heap_context_t*, void*) at C:\Users\asroc\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\3.0.2\cores\esp8266\umm_malloc\umm_malloc.cpp line 549
0x40100a26: free(void*) at C:\Users\asroc\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\3.0.2\cores\esp8266\umm_malloc\umm_malloc.cpp line 595
0x402089c5: String::invalidate() at C:\Users\asroc\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\3.0.2\cores\esp8266/WString.h line 295
0x40207fb3: WebSerialClass::println(char const*) at C:\Users\asroc\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\3.0.2\cores\esp8266/WString.h line 79

[serpinio]

Thank you for looking into it. I've thoroughly tested and couldn't make the board crash with any other length strings, really. Only 8/16 etc ones would cause this. But then again this is an actual buffer overflow so I guess it might behave slightly different for different hardware and env. Still, for my real sketch with sensor readings, LEDs, an Async server and some remote www-API calls it takes just 1-3 of any 8/16 char-long commands to crash the CPU so I don't even need to spam those. I think spamming in this case is only needed in because the example is pretty empty and the chip's RAM is mostly free, so it takes longer to crash the board.

Good luck with finding a fix, Ayush, and thank you for reacting so expediently to the issue.

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[github-actions[bot]]

This issue was closed because it has been stalled for 5 days with no activity.