You should specificaly pay attention to the timers: they are executed within the semaphore/mbox functions (sys_sem_*/sys_mbox_*) and fetch a list of timeouts from an arch-dependent function. This list must be per-thread - if not, timers will be executed in a wrong thread, which may lead to the pcb-list-corruption you saw (by executing tcp_tmr() outside tcpip_thread context).
Simon Lou Cypher wrote: > > Such bugs with corrupt PCB lists have always in the past been two > > threads (e.g. interrupt, timer, or application) active in lwIP at the > > same time. This fits very well with your description. > > I know it has all the characteristics of data corruption by interrupt > handling > and/or task switching, and I'll look further in that direction. > Even though I should have no reason for unexpected reentrancy/data access, > with > cooperative multitasking. > All the system's interrupts are unrelated to lwIP, besides the MAC > controller of > course: but it puts data in a queue unknown to lwIP, and it's later > extracted > (atomically) by a task dedicated to lwIP processing. > > ~ Lou > > > > _______________________________________________ > lwip-users mailing list > [email protected] > http://lists.nongnu.org/mailman/listinfo/lwip-users -- Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
