AsyncPrinter causes soft WDT reset if you send too much data at once

[garbled1]

In my code, I'm doing something similar to the below:

void send_stuff(int i) { char buf[256]; sprintf(buf, "foo %s foo:%s foo:%d\n", var, var, var); ap->printf("%s", buf); ap->printf("%s", buf); }

This causes:

Decoding stack results 0x402054d7: AsyncPrinter::write(unsigned char const, unsigned int) at /home/garbled/Arduino/libraries/ESPAsyncTCP/src/AsyncPrinter.cpp line 136 0x4020e45b: Print::printf(char const, ...) at /home/garbled/.arduino15/packages/esp8266/hardware/esp8266/2.5.2/cores/esp8266/Print.cpp line 74 0x40210815: esp_schedule() at /home/garbled/.arduino15/packages/esp8266/hardware/esp8266/2.5.2/cores/esp8266/core_esp8266_main.cpp line 95 0x40210872: init_done() at /home/garbled/.arduino15/packages/esp8266/hardware/esp8266/2.5.2/cores/esp8266/core_esp8266_main.cpp line 184 0x4020329c: gnhast::gn_update_device(int) at /home/garbled/Arduino/libraries/gnhast-ESP-library/gnhast_async.cpp line 430 0x40216b94: malloc(size_t) at /home/garbled/.arduino15/packages/esp8266/hardware/esp8266/2.5.2/cores/esp8266/umm_malloc/umm_malloc.cpp line 1677 0x4021fa0e: ssputs_r at /home/earle/src/esp-quick-toolchain/repo/newlib/newlib/libc/stdio/nano-vfprintf.c line 233 0x4021b418: _printf_i at /home/earle/src/esp-quick-toolchain/repo/newlib/newlib/libc/stdio/nano-vfprintf_i.c line 194 0x4021fa0e: ssputs_r at /home/earle/src/esp-quick-toolchain/repo/newlib/newlib/libc/stdio/nano-vfprintf.c line 233 0x4021f940: ssputs_r at /home/earle/src/esp-quick-toolchain/repo/newlib/newlib/libc/stdio/nano-vfprintf.c line 180 0x4021b520: _printf_i at /home/earle/src/esp-quick-toolchain/repo/newlib/newlib/libc/stdio/nano-vfprintf_i.c line 244 0x4021fa0e: ssputs_r at /home/earle/src/esp-quick-toolchain/repo/newlib/newlib/libc/stdio/nano-vfprintf.c line 233 0x4021fbf8: _svfprintf_r at /home/earle/src/esp-quick-toolchain/repo/newlib/newlib/libc/stdio/nano-vfprintf.c line 531

I've also noticed if I call ap->println(buf); it causes pretty much the same crash.

If I break the printfs up and have some time between them, I notice the crash goes away. Just doing two in a row like that seems to knock it over...

[stale[bot]]

[STALE_SET] This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.

[garbled1]

This is still happening

[stale[bot]]

[STALE_CLR] This issue has been removed from the stale queue. Please ensure activity to keep it openin the future.

[mhightower83]

@garbled1 Have you tried this with the latest ESPAsyncTCP and the recent 2.6 Arduino Core. With my project, I saw some problems with long streaming debug output sessions that would end with a Soft WDT. Over time with the improvements in Arduino Core (now 2.6) and changes to ESPAsyncTCP (now merged), and fixing some of my own mistakes it has gone away. There was no one thing I noticed changing that fixed this, then again I was making a lot of changes at one time.

BTW: A complete MCVE sketch makes it a lot easier for someone seeing your post to try and observe the issue you are having.

[Aaland]

I found the same or a similar problem. If 2 print or write statements are made in the onData function the write function in AsyncPrinter gets into an indefinitive loop.

The reason is that the write method AsyncPrinter uses a delay(0) loop while the clients canSend reports false. canSend reports false until the client has received ACK for the first printout. During an onData method this will never happen because lwip does not send out anything during the call resulting in onData, it just ignore the output request. Instead lwip waits for the return from the onData and transmits all data queued during the onData together with the ACK.

I have made a fix for it but it changes quite much how AsyncPrinter behaves. In my version AsyncPrinter uses add_data instead of write if onData is in progress and it also buffers data if it can't be sent to the client. When the buffer is full it will drop the data. This has the effect that it is much faster to execute the print statements but if to much is written it will drop data instead of waiting for ACK's from the remote end.

I am trying to do some testing right now but I have a problem with my ESP8266 module stopping me. I have never used git but if I manage to test it with good results I will try to make a pull request.

[stale[bot]]

[STALE_SET] This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.

[stale[bot]]

[STALE_DEL] This stale issue has been automatically closed. Thank you for your contributions.