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
_______________________________________________ lwip-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users
