|Subject:||[lwip-users] ERR_MEM in socket layer lwip_send() on non-blocking|
|Date:||Thu, 20 Nov 2014 12:30:04 +0000|
[using LwIP 1.4.1]
we encountered some instances of lwip_send() setting sock->err to ERR_MEM even on non-blocking sockets.
As ERR_MEM is not a fatal error and as there are plenty of if statements checking for blocking state and doing something different instead of returning this error, I wondered if that is a bug.
In our case, do_writemore() completes the tcp_sndbuff() check and calls tcp_write() which in turn *can* return ERR_MEM at several places.
Apparently, one of those places (we can’t step-debug in that current setup) returns ERR_MEM and back in do_writemore(), the checks for dontblock and len are run through, then the check for if(err == ERR_OK) fails, the else if ((err== ERR_MEM) && !dontblock) also fails and thus the code in else is executed, which sets write_finished =1 and after that the if(write_finished) statement sets the err to ERR_MEM as that is the content of err.
This in turn leads to a situation that feels like it shouldn’t happen.
Shouldn’t the non-blocking write just return EWOULDBLOCK or something along those lines and the user should continue to try sending?
Any ideas? Is this a bug?
PS: in do_write() the return value of do_writemore() is not checked even though it returns err_t [even though it always returns ERR_OK when Core locking is off].
|[Prev in Thread]||Current Thread||[Next in Thread]|