[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Fabian Koch
Subject: [lwip-users] ERR_MEM in socket layer lwip_send() on non-blocking
Date: Thu, 20 Nov 2014 12:30:04 +0000

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,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]