LWIP_ASSERT sockets[i].select_waiting == 0

[hrc-amilcar]

Hello.

Our application running SDK 2.13.0 on RT685 is sporadically failing an assert on line 565 of lwip/src/api/sockets.c:

LWIP_ASSERT("sockets[i].select_waiting == 0", sockets[i].select_waiting == 0);

It happens after wlan is connected and a socket is created. It only happens sometimes and only when creating the second socket. Perhaps between 1-in-10 or 1-in-20 times, so it's difficult to reproduce.

The socket is being created from a FreeRTOS task and there are no other tasks attempting to access or close the socket. The total number of sockets is currently configured as 18.

For some reason, execution doesn't automatically stop in MCUXpresso IDE, but the assert shows up in the log and the IDE hangs there. Once I press the "Suspend" toolbar button, I can see the callstack stopped at:

• sys_assert()
• alloc_socket()
• socket()
• ...

However, when watching sockets[1] in the Expressions view, select_waiting is already zero. So perhaps it has been cleared from another task or interrupt.

I don't see how select_waiting has been incremented since the socket is in the process of being created and no other tasks should be using the socket or calling select.

I saw a forum post pointing to a related fix but it seems this patch has already been applied:

lwip.git - lwIP - A Lightweight TCPIP stack (nongnu.org)

Any ideas as to what could be happening?

Thank you.

[hrc-amilcar]

Hello Omar. Thank you for the response.

This is on a custom board. We're trying to reproduce the issue on the EVK with sample code but it's proving to be difficult to reproduce.

One speculation we have is that the issue could be stemming from multiple FreeRTOS tasks attempting to create and close sockets. It doesn't appear that LWIP is thread-safe when it comes to multiple tasks creating sockets.

For example:

• lwip_close calls get_socket.
• get_socket calls tryget_socket.
• tryget_socket calls tryget_socket_unconn.
• tryget_socket_unconn calls tryget_socket_unconn_nouse which returns a pointer to the lwip_sock structure corresponding to the socket index without any checking.

We noticed that SYS_ARCH_PROTECT is not called when accessing the sockets[] array during close, as it is during alloc_socket.

This could imply that one FreeRTOS task could be closing a socket in array slot 0 while another task gets the same slot during an alloc. Then the close would continue to close the socket that is in the middle of creation. (?)

We see that LWIP_NETCONN_FULLDUPLEX is available, but we're not sure if that's meant to protect socket creation from multiple tasks.

Can two tasks create independent sockets without affecting each other, and without using FULLDUPLEX define?

This is just speculation. We're continuing to investigate.

Best regards.

[Omar_Anguiano]

Hello
I hope you are well.

It would be helpful if you provide me with some additional information regarding your application.|
Are you using the EVK to reproduce this issue or are you using a custom board?
Additionally, how different is your code from the examples we provide on the SDK? Is there some extra functionality added?

Best regards,
Omar