[lwip-users] do_writemore: invalid length! assertion

0 views
Skip to first unread message

Yoav Nissim

unread,
Dec 27, 2009, 5:34:36 AM12/27/09
to lwip-...@nongnu.org
Hello.
I have been using lwIP and its socket layer on a Windows platform for a
while now. Its been used by an HTTP client only (for now).
Recently I have encountered the aforementioned assert (and crash).
Investigating this further has directed me to the following sequence of
events:

1. A TCP socket is initialized and connects to a streaming server
2. Thread A reads data from the socket.
3. Thread B sends data on the socket. This send operation is special as
it sends more than tcp_sndbuf() bytes.
4. do_writemore() does not ACK the waiting Thread B, since it waits for
sent_tcp() to trigger sending the next chunk of data.
5. Received data for the socket is processed, do_recv() is called, and
the op_completed semaphore is signalled to complete *the* operation.
6. Thread B wakes up instead of thread A, destroying the message (a
local variable).
7. tcp_sndbuf() bytes are sent, and tcp_sent() calls do_writemore() with
a pointer to the destroyed message.

Is this sequence plausible or have I missed something?
Assuming the sequence is valid, does lwIP support more than a single
thread handling a socket? If so, wouldn't we need a set of locks for all
netconn operations that can happen simultaneously (if there are any)?

Yoav.


_______________________________________________
lwip-users mailing list
lwip-...@nongnu.org
http://lists.nongnu.org/mailman/listinfo/lwip-users

gold...@gmx.de

unread,
Dec 27, 2009, 6:35:28 AM12/27/09
to Mailing list for lwIP users
Yoav Nissim wrote:
> [..]

> 2. Thread A reads data from the socket.
> 3. Thread B sends data on the socket.
Unfortunatly, using a socket (or netconn) from multiple threads at the
same time is currently not supported by lwIP.
> [..]

> If so, wouldn't we need a set of locks for all
> netconn operations that can happen simultaneously (if there are any)?
>
This is the reason why it isn't supported: it would move the stack away
from being lightweight, needing more protection mechanisms.

Simon

Reply all
Reply to author
Forward
0 new messages