[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lwip-devel] [bug #46701] Non-standard close behavior can result in sock
From: |
Joel Cunningham |
Subject: |
[lwip-devel] [bug #46701] Non-standard close behavior can result in socket/netconn leaks |
Date: |
Wed, 16 Dec 2015 23:03:33 +0000 |
User-agent: |
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 |
URL:
<http://savannah.nongnu.org/bugs/?46701>
Summary: Non-standard close behavior can result in
socket/netconn leaks
Project: lwIP - A Lightweight TCP/IP stack
Submitted by: jcunningham
Submitted on: Wed 16 Dec 2015 11:03:32 PM GMT
Category: sockets/netconn
Severity: 3 - Normal
Item Group: Change Request
Status: None
Privacy: Public
Assigned to: None
Open/Closed: Open
Discussion Lock: Any
Planned Release:
lwIP version: git head
_______________________________________________________
Details:
I've encountered non-standard close behavior that can result in socket and
netconn leaks. Long explanation here, please bear with me
My application is using non-blocking sockets and when trying to close the
socket, EAGAIN is returned because the snd_buf in the PCB is full and we can't
send a FIN
Since the socket is set to non-blocking, the close returns without actually
closing the socket. My application, written against standard BSD sockets,
isn't checking for EAGAIN as that would not normally be returned from close
unless SO_LINGER was set and the timeout elapsed. Even if it was, it doesn't
mean the socket is still allocated. With this behavior, non-blocking
applications need a wait loop around close until it returns successfully.
I double checked the BSD behavior in my Steven's book (UNIX Network
Programming Volume 1, 3rd Edition: The Sockets Networking API) and it
documents (section 4.9):
The default action of close with a TCP socket is to mark the socket as closed
and return to the process immediately. The socket descriptor is no longer
usable by the process: It cannot be used as an argument to read or write.
But, TCP will try to send any data that is already queued to be sent to the
other end, and after this occurs, the normal TCP connection termination
sequence takes place.
The section on SO_LINGER explains returning EWOULDBLOCK during a SO_LINGER
timeout and I can provide that text if it is helpful.
So I see the following deviations:
0 close in the default case of SO_LINGER off shouldn't be blocking regardless
of blocking/non-blocking socket configuration. The closure happens
asynchronously
0 close shouldn't ever leave socket resources allocated
0 close should only be returning EWOULDBLOCK in the case of a SO_LINGER
timeout (or using non-blocking sockets with SO_LINGER configured with a
timeout)
I also found this commit in lwip_netconn_do_close_internal, indicating the
deviation #1 is known:
f(err == ERR_MEM) {
/* Closing failed because of memory shortage */
if (netconn_is_nonblocking(conn)) {
/* Nonblocking close failed */
close_finished = 1;
err = ERR_WOULDBLOCK;
} else {
/* Blocking close, check the timeout */
#if LWIP_SO_SNDTIMEO || LWIP_SO_LINGER
s32_t close_timeout = LWIP_TCP_CLOSE_TIMEOUT_MS_DEFAULT;
/* this is kind of an lwip addition to the standard sockets: we wait
for some time when failing to allocate a segment for the FIN */
#if LWIP_SO_SNDTIMEO
if (conn->send_timeout >= 0) {
close_timeout = conn->send_timeout;
}
I'm thinking why behave differently for nonblocking sockets since we aren't
supposed to be blocking for either case? Shorter term fix might just to
remove the check netconn_is_nonblocking() and this would make sure close can
complete the FIN up till the 20 second timeout.
Longer term, we could change over to having the closure complete
asynchronously and having close always deallocate resources. Thoughts?
_______________________________________________________
Reply to this item at:
<http://savannah.nongnu.org/bugs/?46701>
_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/
- [lwip-devel] [bug #46701] Non-standard close behavior can result in socket/netconn leaks,
Joel Cunningham <=