Hallo,
since I have some problems with ASSERTS where it was suspected these are
threading issues I added some debug code which check if tcpip functions are
called from another thread than the tcpip thread.
For this I added a function sys_get_thread_id in sys_arch.h and a global
variable that stores th the thread ID of the TCPIP thread on startup.
Also I added a check in sockets.h. I added the element threadId in struct
lwip_sock and set it with the ID of the calling thread in alloc_socket. Then
I compare in get_socket the ID in lwip_sock with the calling thread and the
tcpip thread.
This could be a useful debug feature for all LWIP users to be added in the
LWIP Stack?
Still (without any threading issues) I have following two problems with the
stack:
1. unsent oversize mismatch
When stressing my system with a flood of HTTP get requests getting JPEG
images, I get (very sporadically) the assert "unsent_oversize mismatch (pcb
vs. last_unsent)"
TCP_OVERSIZE was set to TCP_MSS. I set TCP_OVERSIZE to 0 now, so this can't
happen any more. But still I'm a little bit concerned about that.
2. read after shutdown
The webserver I use has following sequence for shutdown:
if (sp->sock >= 0) {
socketSetBlock(sid, 0);
if (shutdown(sp->sock, SHUT_WR) >= 0) {
recv(sp->sock, buf, sizeof(buf), 0);
}
close(sp->sock);
}
When "#define MEMP_SANITY_CHECK 1" is set I get sporadically an assert from
the sanity check.
When I remove the recv after shutdown it works. Maybe this receive is the
problem?
I'v seen following comment in sockets.c
/**
* Unimplemented: Close one end of a full-duplex connection.
* Currently, the full connection is closed.
*/
int
lwip_shutdown(int s, int how)
Does this mean that shutdown(sp->sock, SHUT_WR) does a SHUT_RDWR. What could
happen with the recv then?
Best regards,
Sandra
_______________________________________________
lwip-users mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/lwip-users
