lwip-devel
[Top][All Lists]
Advanced

[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/




reply via email to

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