UDP Crash with versions above 2.5.2

[SvenSiwek]

Basic Infos

• [X ] This issue complies with the issue POLICY doc.
• [ X] I have read the documentation at readthedocs and the issue is not addressed there.
• [ X] I have tested that the issue is present in current master branch (aka latest git).
• [ X] I have searched the issue tracker for a similar issue.
• [ X] If there is a stack dump, I have decoded it.
• [X ] I have filled out all fields below.

Platform

• Hardware: [ESP8266]
• Core Version: [2.6.0 & 2.6.1]
• Development Env: [Arduino IDE]
• Operating System: [Windows]

Settings in IDE

• Module: [LOLIN (WEMOS) D1 R2 & mini]
• Flash Mode: [qio|dio|other]
• Flash Size: [4MB]
• lwip Variant: [v1.4|v2 Lower Memory|Higher Bandwidth]
• Reset Method: [ck|nodemcu]
• Flash Frequency: [40Mhz]
• CPU Frequency: [80Mhz|]
• Upload Using: [OTA|SERIAL]
• Upload Speed: [other]

Problem Description

I am pretty new to this all. So please be polite with me.
I do have a working sketch with version 2.5.2.
I updated to 2.6.1
The WEMOS does reboot after a certain time (10 to 15 seconds) with heavy ingoing udp traffic.

I downgraded to 2.6.0
The WEMOS does reboot after a certain time (10 to 15 seconds) with heavy ingoing udp traffic.

I downgraded to 2.5.2
The WEMOS does work as expected.

Since I am pretty new to this all (NodeEMU etc),
is there a "how to" to provide you with additional infos - if needed?

I am willing to help...

Sven

#include <ESP8266WiFi.h>
#include <WiFiUdp.h>

// Wi-Fi network to connect to (if not in AP mode)
 char* ssid = "XXXXXX";
 char* password = "XXXXXXXXXXXXXXXXXXXX";
 
#define BUFFER_LEN 1024
unsigned int localPort = 7777;

// buffers for receiving and sending data
char packetBuffer[1024]; //buffer to hold incoming packet,


// An EthernetUDP instance to let us send and receive packets over UDP
WiFiUDP port;

void setup() {
  WiFi.setSleepMode(WIFI_NONE_SLEEP);
  Serial.begin(115200);
  delay(100);
  Serial.setDebugOutput(true);

  Serial.println();
  Serial.print( F("Heap: ") ); Serial.println(system_get_free_heap_size());
  Serial.print( F("Boot Vers: ") ); Serial.println(system_get_boot_version());
  Serial.print( F("CPU: ") ); Serial.println(system_get_cpu_freq());
  Serial.print( F("SDK: ") ); Serial.println(system_get_sdk_version());
  Serial.print( F("Chip ID: ") ); Serial.println(system_get_chip_id());
  Serial.print( F("Flash ID: ") ); Serial.println(spi_flash_get_id());
  Serial.print( F("Flash Size: ") ); Serial.println(ESP.getFlashChipRealSize());
  Serial.print( F("Vcc: ") ); Serial.println(ESP.getVcc());
  Serial.println();
  WiFi.mode(WIFI_STA);
  Serial.printf("Connecting to %s\n", ssid);
  if (String(WiFi.SSID()) != String(ssid)) {
    WiFi.begin(ssid, password);
  }
  delay(1000);
  port.begin(localPort);
  Serial.println("UDP started"); 
 
 
}
void loop() {
  // if there's data available, read a packet
  int packetSize = port.parsePacket();
  if (packetSize) {
    // read the packet into packetBufffer
    int len = port.read(packetBuffer, BUFFER_LEN);
    Serial.print("Packet.\n");
  }
  delay(100);
  Serial.print("Round.\n");
}

On Linux do

$ cat /dev/random | netcat -u  172.16.178.41 7777

Result:

Round.
Packet.
Fatal exception 29(StoreProhibitedCause):
epc1=0x4000df64, epc2=0x00000000, epc3=0x00000000, excvaddr=0x00000000, depc=0x00000000

Exception (29):
epc1=0x4000df64 epc2=0x00000000 epc3=0x00000000 excvaddr=0x00000000 depc=0x00000000

>>>stack>>>

ctx: sys
sp: 3fffec10 end: 3fffffb0 offset: 01a0
3fffedb0:  4021f643 0000b5bc 00000005 4021f5d8  
3fffedc0:  00000002 4021f57f 00000002 4021e6d8  
3fffedd0:  4021e701 3fffee80 3ffed9c8 00000016  
3fffede0:  4021c174 3fffee80 3ffed874 3ffed200  
3fffedf0:  3ffe9cc0 3fffee80 3fffee80 00000000  
3fffee00:  534d4853 03c9ef00 4010274a 00000100  
3fffee10:  3ffe962c 7fffffff 00000000 00000001  
3fffee20:  402184d5 00000080 00000022 00000000  
3fffee30:  ffffffcf 3ffed388 3ffe9cd0 3ffed9c8  
3fffee40:  3ffec830 0000002f 00000000 4021ce6b  
3fffee50:  00000000 3ffef31c ffffffcf 00000000  
3fffee60:  00000000 3ffed9c8 00000010 0000000f  
3fffee70:  40000f58 00000000 45fad8c3 00000000  
3fffee80:  00000000 00310101 00640100 00000043  
3fffee90:  3ffe9ce4 00000038 3ffe9cf7 3ffe9cd8  
3fffeea0:  00000000 3ffe9ce4 3ffe9cea 3ffe9d00  
3fffeeb0:  00000000 00000000 3ffe9d06 00000000  
3fffeec0:  00000000 00000000 00000000 00000000  
3fffeed0:  00000000 00000000 0000002f 00000000  
3fffeee0:  3ffef6e4 4021c8de 3ffec830 3ffef31c  
3fffeef0:  00000000 3ffed9c8 3ffec830 3ffe9cc0  
3fffef00:  3ffe9cc0 00000060 00000000 0000002f  
3fffef10:  00000000 3ffe9cca 40226023 3ffec830  
3fffef20:  3ffe9cb4 3fffdcc0 3ffe8e68 3ffe8e68  
3fffef30:  00000080 3ffec830 00000000 3fffdcb0  
3fffef40:  402258e3 3fffdab0 00000000 4022c813  
3fffef50:  3ffe8e68 40000f49 3fffdab0 40000f49  
3fffef60:  40000e19 40001878 00000002 00000000  
3fffef70:  3fffff10 401048a5 40001878 00000002  
3fffef80:  401048ab 46060c02 42620005 01678002  
3fffef90:  4010000d 21616063 60016680 063d3168  
3fffefa0:  402247c4 3fffef3c 4022477d 3fffff68  
3fffefb0:  3fffffc0 00000000 00000000 feefeffe  
3fffefc0:  feefeffe feefeffe feefeffe feefeffe  
3fffefd0:  feefeffe feefeffe feefeffe feefeffe  
3fffefe0:  feefeffe feefeffe feefeffe feefeffe  
3fffeff0:  feefeffe feefeffe feefeffe feefeffe  
3ffff000:  feefeffe feefeffe feefeffe feefeffe  
[...]
3ffffc90:  feefeffe feefeffe feefeffe feefeffe  
3ffffca0:  feefeffe feefeffe feefeffe feefeffe  
3ffffcb0:  feefeffe feefeffe feefeffe 00000000  
3ffffcc0:  3ffffe20 00000000 3ffffe20 4020a51e  
3ffffcd0:  feefeffe 3ffffdc3 feefeffe feefeffe  
3ffffce0:  feefeffe feefeffe feefeffe 00000004  
3ffffcf0:  3ffffe20 00000004 3ffffe20 4020a51e  
3ffffd00:  feefeffe 3ffe86a8 3ffffd30 feefeffe  
3ffffd10:  feefeffe feefeffe feefeffe 4020a454  
3ffffd20:  3ffffe20 3ffe86a8 3ffffd80 402068a8  
3ffffd30:  00000004 feefeffe feefeffe 00000001  
3ffffd40:  00000000 00000001 3ffffe20 4020a51e  
3ffffd50:  feefeffe 3ffe8678 feefeffe feefeffe  
3ffffd60:  feefeffe feefeffe feefeffe 3ffe8678  
3ffffd70:  00000000 3ffe8679 3ffffe20 4020a708  
3ffffd80:  00000000 00000004 00000000 00000000  
3ffffd90:  00000004 00000013 fe302073 feefeffe  
3ffffda0:  feefeffe feefeffe feefeffe feefeffe  
3ffffdb0:  feefeffe feefeffe feefeffe feefeffe  
3ffffdc0:  0000000a 40104a88 0000000a 00000000  
3ffffdd0:  40001da0 0000000a 00000000 feefeffe  
3ffffde0:  3fffff50 3fffff20 0000000c 3ffe8304  
3ffffdf0:  00000004 00000001 00000000 feefeffe  
3ffffe00:  3ffecf20 4010261b feefeffe 3ffeeae8  
3ffffe10:  3ffee9bc 3ffe8304 00000040 40207ef1  
3ffffe20:  3ffffee3 2c9f0300 0000002c ffff0208  
3ffffe30:  3ffffed0 0000003f 000000cb 401006a4  
3ffffe40:  40228f77 3fffff20 3fffff20 3ffeeae8  
3ffffe50:  3fffff20 3ffef83c 00000020 4010092f  
3ffffe60:  3ffeeae8 00000000 00000004 fffffffe  
3ffffe70:  ffffffff 00000000 00000004 401002e8  
3ffffe80:  00000004 00000000 000a534d 40203e51  
3ffffe90:  3ffed3bf 00000004 3fffff7c 40202cd4  
3ffffea0:  3ffe84c8 3fffff7c 3fffff30 40202d0a  
3ffffeb0:  000005e8 3ffee980 3fffff7c 40201c48  
3ffffec0:  534d4853 00000000 00000000 00000001  
3ffffed0:  00001e61 3ffee568 00000020 40100964  
3ffffee0:  32313732 63697361 6c656773 37363931  
3ffffef0:  3ffe86b5 00000000 616e000a 40203e51  
3fffff00:  3ffe86b5 00000000 61500064 40203e51  
3fffff10:  3ffe8685 3ffee568 00000020 00000001  
3fffff20:  00001170 0000022e 0000022e 401006a4  
3fffff30:  3ffe868e 00000000 52000a2e 40203e51  
3fffff40:  3ffe868e 3fff02c4 00000020 4010092f  
3fffff50:  401050c5 012f3f0a 3ffeeb48 00000000  
3fffff60:  3ffee0b0 3ffeeb48 00000064 3ffeeb48  
3fffff70:  3fffdad0 3ffeeae8 40202fa4 3fffefa0  
3fffff80:  3ffeeb48 3fffdad0 3ffeeae8 4020359b  
3fffff90:  3fffdad0 3ffee9bc 3ffee568 40201204  
3fffffa0:  3fffdad0 00000000 3ffeeaa8 402030d4  
<<<stack<<<

 ets Jan  8 2013,rst cause:2, boot mode:(3,6)

load 0x4010f000, len 1384, room 16 
tail 8
chksum 0x2d
csum 0x2d
v482516e3
~ld
⸮bl`�r⸮n�lph⸮
Heap: 51016
Boot Vers: 6
CPU: 80
SDK: 2.2.2-dev(5ab15d1)
Chip ID: 6637503
Flash ID: 1458208
Flash Size: 4194304
Vcc: 65535

Connecting to SHMS
UDP started
scandone
state: 0 -> 2 (b0)
Round.
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 6
cnt 
Round.
Round.
Round.
Round.
Round.
Round.
Round.
Round.
Round.
Round.
Round.
Round.
Round.
Round.
Round.
Round.
Round.
Round.
Round.

connected with SHMS, channel 1
dhcp client start...
ip:172.16.178.41,mask:255.255.255.0,gw:172.16.178.1
Round.
Packet.
Round.
Packet.
Round.
Packet.
Round.
Packet.
Round.
Packet.
Round.
Packet.
Fatal exception 29(StoreProhibitedCause):
Fatal exception 29(StoreProhibitedCause):
Fatal exception 29(StoreProhibitedCause):
Fatal exception 29(StoreProhibitedCause):
Fatal exception 29(StoreProhibitedCause):
Fatal exception 29(StoreProhibitedCause):
Fatal exception 29(StoreProhib
 ets Jan  8 2013,rst cause:4, boot mode:(3,6)

wdt reset
load 0x4010f000, len 1384, room 16 
tail 8
chksum 0x2d
csum 0x2d
v482516e3
~ld
⸮bl`�r⸮n�lph⸮
Heap: 51016
Boot Vers: 6
CPU: 80
SDK: 2.2.2-dev(5ab15d1)
Chip ID: 6637503
Flash ID: 1458208
Flash Size: 4194304
Vcc: 65535

Connecting to SHMS
UDP started
scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 6
cnt 
Round.
Round.
Round.
Round.
Round.
Round.
Round.
Round.
Round.
Round.
Round.
Round.
Round.
Round.
Round.
Round.
Round.
Round.
Round.

connected with SHMS, channel 1
dhcp client start...
ip:172.16.178.41,mask:255.255.255.0,gw:172.16.178.1
Round.
Round.

[TD-er]

Do you "server" the UDP related code with regular intervals?
Just like "serving" the webserver, you must also make regular calls to see what packets have to be processed for UDP.

[devyte]

@SvenSiwek the issue template you filled out requires an MCVE. Without that there isn't much we can do.
Please edit your OP and add a MCVE sketch with which the issue can be reproduced. If there is additional info involved, such as needing a linux script or similar to reproduce, please add that as well.

[SvenSiwek]

Okay I found out what MCVE means. I ll provide one.

It would be fine if you explain what OP means, which I have to edit.

My English is not that good, and as I wrote I am new to this.
Thx
Sven

[devyte]

Original Post

[TD-er]

On Linux do

cat /dev/random | netcat -u 172.16.178.41 7777

Hmm that sounds like "lots of traffic" and "large packets".
Both are a very good receipt for crashes on these units.
Have you also tried limiting the speed by setting an interval (-i) and maybe also use shorter messages.
I don't know what netcat will consider a chunk of data, when processing /dev/random.

[devyte]

You are processing packets once per loop. You also have delay(100) in the loop. That effectively limits you to 10 packets per second. If you send faster than that, the esp will accumulate them, run out of mem, and crash.
Closing due to user error.

[devyte]

Also, you're reading at most 1024 bytes into the buffer. If the packet is bigger, there are remaining bytes unread.

[SvenSiwek]

Why do you close this?

This ist not an user error. You're really doing it very easy.

If I send too many packets too fast, that's my problem. The nodemcu must therefore not crash. If she loses packages that's okay.

I checked my MCVE against 2.5.2 which works as expected without any crash.

So I will stick to that version.

Thank you for taking my time.
I will think for the future again to report errors, if I am helped in this way.
Translated with Google.

Sven

[devyte]

I closed because I still don't see a core issue. That does not mean end of discussion.
Also, if what you need is general help, this is not the place for it, because this is an issue tracker, meant for tracking issues in the core, and not a general support forum.
Finally, your reports help yourself before anyone else, because you are the user faced with the issue. In this case, as the primary interested party, it is up to you to continue investigating and providing info, until you either show a core issue, in which case I'll reopen, or you find a mistake in your code, in which case you'll probably immediately realize how to fix it.

As for 2.5.1, it would intermittently lose incoming packets independently of receiving speed, and that was addressed. If you don't want to process all incoming, it is your responsibility to receive and discard unwanted packets, because there is no way to differentiate between your use case of unwanted packets and somebody else who wants to maximize reception.
And btw, it is true that udp packets can get dropped in traffic, but it is not ok to receive packets and lose them in our software before passing them to the user app.

[SvenSiwek]

Hi,
I opened this issue, because something that works with 2.5.2 does not work with 2.6.1 and up.

If you arent interested in finding the cause of that, than it is that way,

For me its pretty easy. I generate an udp stream of packets on the server side.
It is not importand for me that every single udp arrives in the sketch.

But this packet stream should not crash the device - under no circumstances.
This is what happens with version 2.6.1 and up.

So, too much udp packets in a to short timerange crashes the device. That is core.

Sven

[TD-er]

@SvenSiwek Please read his reply again.
It was an intentional change (aka. bug fix) to change behavior and not drop packets.
I do agree the result is somewhat unfortunate, to cause a crash.

Maybe you can change the function in your code to read the entire packet (read until packet length is processed) and also not waiting for 100 msec every loop.
In a few 100 msec the memory of the ESP is full when receiving at max. speed, especially if you only read 1024 bytes.
Also I am not entirely sure your code does continue to read on the same packet if you go through the next loop. So that may leave the rest of the packet in RAM, causing the RAM to fill up and all kinds of things will then fail as lots of memory allocations will fail.

[SvenSiwek]

Hi,

the goal, at last for me was, to provide a MCVE, which I did.

If a bug fix results in somewhat like a possible DoS it is not a good one.
Maybe you can install a switch to get the old behavior back.

To the root of that :
My daughter wanted to have a nice light show with LEDs, which she can control via mobile phone.
As I myself am a programmer (COBOL, Java, PHP), I thought, can not be that hard and I came across the ESP and fastled.
That works great https://github.com/jasoncoon/esp8266-fastled-webserver .
That was not enough for us. It should also give great effects to match music. Then I found https://github.com/scottlawsonbc/audio-reactive-led-strip .

I have combined both in a sketch and it works fine - just up to version 2.5.2.

Now there was the update to 2.6.1 and higher.
It does not work with these versions.
I thought, okay then I'll call it. Something does not seem to work as it should.

The Visualization-Server sends UDP light instructions to the ESP. Always 4 bytes. The first byte Addresses the number of the LED. The other three bytes are RGB color values.

The source code has remained pretty much the same.

Translated with Google
Sven