[lwip-users] ERR_MEM in socket layer lwip_send() on non-blocking

[Fabian Koch]

Hey all,

 

[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].

 

Kind regards,
Fabian