[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lwip-devel] [bug #25821] lwip_recvfrom failed to reset sock->rcvevent,
From: |
Wim Dumon |
Subject: |
[lwip-devel] [bug #25821] lwip_recvfrom failed to reset sock->rcvevent, communication lost sync totally |
Date: |
Thu, 19 Mar 2009 16:02:12 +0000 |
User-agent: |
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.7) Gecko/2009021910 Firefox/3.0.7 |
Follow-up Comment #2, bug #25821 (project lwip):
I have just noticed a similar thing. lwip_select() says that there is
something to read on a non-blocking socket, but when I do read data, the
lwip_recvfrom call blocks while reading from the mbox, waiting for the mutex
(I used the windows port for now). And that causes my program to deadlock...
I traced this back and it always happens on heavy traffic conditions (e.g.
opening many connections and transferring data over them), when the mbox is
full (breakpoint on return ERR_MEM in recv_tcp() in api_msg.c). RCVPLUS events
are received by the sockets layer, but there is no data (mbox is empty, but
the receive event counter isn't, and lwip_recvfrom performs a blocking read
from an empty buffer).
For now, I moved
SYS_ARCH_INC(conn->recv_avail, len);
and
API_EVENT(conn, NETCONN_EVT_RCVPLUS, len);
to just before the return ERR_OK, and the deadlock disappears. But is this
correct?
I haven't tested this for UDP, but there seems to be something similar going
on there (at the end of recv_udp).
_______________________________________________________
Reply to this item at:
<http://savannah.nongnu.org/bugs/?25821>
_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/