[lwip-devel] [bug #27709] conn->err race condition on netconn_recv() timeout

[Simon Goldschmidt]

URL:
  <http://savannah.nongnu.org/bugs/?27709>

                 Summary: conn->err race condition on netconn_recv() timeout
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: goldsimon
            Submitted on: Do 15 Okt 2009 14:23:01 GMT
                Category: None
                Severity: 3 - Normal
              Item Group: Faulty Behaviour
                  Status: None
                 Privacy: Public
             Assigned to: goldsimon
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: 1.3.2
            lwIP version: 1.3.1

    _______________________________________________________

Details:

This was reported by David Shmelzer on lwip_users:

First mail:
>>>>>> snip >>>>>>
I upgraded to 1.3.1 and it fixed the zero timeout problem I was having.
Thanks.
However, I'm still getting a peculiar issue where netconn_recv erroneously
sets conn->err to ERR_CLSD after 3 or so packets in the following section:


    /* If we are closed, we indicate that we no longer wish to use the socket
*/
    if (p == NULL) {
      memp_free(MEMP_NETBUF, buf);
      /* Avoid to lose any previous error code */
      if (conn->err == ERR_OK) {
-->     conn->err = ERR_CLSD;
      }
      return NULL;
    }

I put a breakpoint there and determined that the preceding call to
sys_arch_mbox_fetch() returns timeout so conn->err should be ERR_TIMEOUT and
not ERR_OK.
So somewhere between sys_arch_mbox_fetch() and the above code conn->err is
being set to ERR_OK.
If I send another packet, ignoring the closed error, it fixes itself. 
I then receive the preceding packet and the one just sent.
I'm calling netconn_recv() in a loop in another thread with a zero timeout.
help?
<<<<<< snap <<<<<<

Second mail:
>>>>>> snip >>>>>>
I traced the problem to conn->err being assigned a value in separate
threads.
One in recv_tcp() and another in netconn_recv().

recv_tcp() is called from the tcpip_thread and netconn_recv() is called
from a separate thread. 
Am I using netconns incorrectly? 
If so, shouldn't conn->err be a thread safe variable since it is
accessed from tcpip_thread as well as the thread using the netconn api?
conn->recv_avail is thread safe.
<<<<<< snap <<<<<<





    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?27709>

_______________________________________________
  Nachricht geschickt von/durch Savannah
  http://savannah.nongnu.org/