I see a couple issues with FreeRTOS_closesocket.
The first issue I see here. The zero time-out is unnecessary and
the comment is misleading:
because in xSendEventStructToIPTask we find this time-out overridden when called
from the IP-Task:
A time-out of portMAX_DELAY would be better here,
especially since nobody is expecting to handle the return value of FreeRTOS_closesocket.
Which leads to issue number two.
That is when called from the IP-Task it is necessary to handle the return value:
But both calls to FreeRTOS_closesocket from FreeRTOS_TCP_IP.c fail to
handle the return value from FreeRTOS_closesocket, and therefore may cause
memory leaks.
Note, that I have a test case that triggers the closesocket in vTCPStateChange,
while the closesocket in prvTCPSocketCopy is believed to be unreachable.
I can share the test case with you if you want.
A similar issue may happen when a listening socket is closed with FreeRTOS_closesocket
while there are still pending accepted sockets with u.xTCP.bits.bPassQueued or
u.xTCP.bits.bPassAccept set, these sockets can neither be closed nor accepted any more.
Note however that when I try to create test case for this I usually do not see a memory
leak but instead I see a crash, because when I close the socket I also delete the
signal set, with FreeRTOS_DeleteSocketSet, but while the FreeRTOS_closesocket
runs in the context of the IP-Task the SocketSet_t is deleted right away, when the
socket may still be holding a reference to the Socket Set, which gets signalled once
the PassAccept bit gets set.
A similar race may of course also happen with UDP sockets, when the socket is
deleted and a packet is received at the same time.