lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] LWIP - TCP receive assert failed


From: Sylvain Rochet
Subject: Re: [lwip-users] LWIP - TCP receive assert failed
Date: Sat, 10 Jan 2015 18:17:47 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

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

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]