Multiple sockets seem to cause crashing.

[MatthewMenze]

The socket close handler reports the incorrect socket closing, and seems to be related so some sort of device crash.

I am using the LTE shield with a Metro M4 Airlift Express board, using the hardware serial interface.

• My firmware starts up the device, then opens 1 UDP socket to periodically writes a small JSON to the server, this socket behaves as expected, and takes up socket 0 on the LTE module.

• Next my firmware opens two additional TCP sockets, which each listen on a different port for periodic data packets, taking up sockets 1 & 2. These sockets are polled with the library function poll() on every program loop. They seem to read data correctly as I send out packets. However, upon the connection closing the library reports to the socket closed callback that socket 3 has closed. After a number of connection close events, it starts reporting socket 4, then 5, then 6. When it reports socket 5/6 it stops triggering the socket read callback. Then shortly after it seems to stop functioning entirely, and I get TCP errors on my transmitting device saying unable to connect. It seems the same socket value is given regardless of which port I send a packet to (IE, the socket reported to close is unrelated to which listening socket I hit)

• This issue seems to be partially mitigated if I call socketClose() on the misreported socket. Although it will still crash with enough events.

Based on experimentation, I believe this is an issue of incorrectly tracking and handling socket events, causing resources to be incorrectly de-allocated as sockets are created and destroyed. Maybe this is related to the memory issues I see mentioned in other issues and commits?