Hi Jackie,
On Mon, Jan 05, 2015 at 11:59:00PM +0800, Jackie wrote:
> Hi all,
>
> Recently when I am working on LWIP to do some stress test, e.g.
> continuously uploading data to a server via TCP connection, the device
> often crashed on an assert statement in tcp_receive(),
>
> if (pcb->snd_queuelen != 0) {
> LWIP_ASSERT("tcp_receive: valid queue length", pcb->unacked !=
> NULL ||
> pcb->unsent != NULL);
> }
>
> After debugging the crash case, I found some possible cause that the pcb
> structure has been corrupted by another thread during a context switch.
> I singled out one likely candidate, tcp_slowtmr(). In this timer, it
> calls another function tcp_pcb_purge(), in which it resets both unacked
> and unsent queue to NULL but without setting queuelen to 0. In some
> cases (like tcp state is FIN_WAIT_2), this timer will interrupt the
> current tcp thread in a preemptive OS environment, modifying the current
> pcb before hitting the assert statement afterwards.
>
> How likely will it be if so? Has anyone encountered a similar issue? Any
> suggestions?You are not specific enough to be able to conclude, but, as usual, it looks like a broken port or usage which do not follow lwIP threading model. Summary: - Do *NOT* call anything in interrupt context, nothing, never, never, use your OS semaphore signaling to an Ethernet/serial/… RX thread - memp_* functions are thread-safe if SYS_LIGHTWEIGHT_PROT is set, and again, thread safe does not mean it is interrupt safe, especially if your hardware does nested interrupts - Do *NOT* call any function from the RAW API outside lwIP thread - Use Netconn or Socket API in others threads, but keep in mind you should not share a Netconn/Socket control block between threads, (or use proper locking if you really have to, of course). Sylvain
signature.asc
Description: Digital signature
_______________________________________________ lwip-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users
