[Top][All Lists]

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

Re: [lwip-users] Reentrency problem within mem.c module

From: Simon Goldschmidt
Subject: Re: [lwip-users] Reentrency problem within mem.c module
Date: Thu, 25 Oct 2007 17:23:43 +0200


I also encountered this problem when working with a DMA enabled MAC. As you said, this bug does still exist in CVS head, only nobody ever really cared to change it, I think.

The reason that _I_ didn't change it is CVS head includes a new option to forware mem_malloc() calls to new memp pools of different sizes (this was introduced to prevent memory fragmentation). And since memp_malloc() uses SYS_ARCH_PROTECT macros only, this solves your problem. The downside is that while memory fragmentation is prevented, memory usage is higher (because of the fixed size pools) _and_ you dont have it in v1.1.1!

The reason mem_malloc() doesn't use the SYS_ARCH_PROTECT macros is that this disables interrupt for too long time span (if your heap is big and fragmented). And if your product has higher priority tasks than the TCPIP stack, these tasks might get slowed down.

A generic solution for this problem is to either let the user configure which protection to use or to put freed memory blocks on a list that i later processed in normal context. But to implement this, we would need a sys_sem_trywait() in the sys layer, which we currently haven't.

Anyway, could you please file a bug report on savannah so this bug doesn't get lost (if we don't fix it, it has to be documented).


Am 25.10.2007 um 16:55 schrieb EVS Hardware Dpt:


Recently we found a problem in our product. After some times we found that we had a reentrency problem within mem.c module.

In our application when sending data to our Ethernet driver, the driver call pbuf_ref(p) for each pbuf it receives then in the TX ISR handler, it calls pbuf_free(p). On the receive side, RX interrupt simply set a flag telling that some packets are waiting for service. I believe a lot of people here are using this kind of mechanism.

So beside the TX End ISR handler which only call pbuf_free as necessary, all other parts of the stack are running at normal level (ie not interrupt level). So there is effectively only one thread for the stack. We dont have an OS (NO_SYS = 1) but SYS_LIGHTWEIGHT_PROT = 1. Stack version is currently 1.1.1, but latest CVS version still exhibit this behavior.

Our problem :

We are receiving a lot of data (70MB/s rate on Gigabit interface), so the stack send a lot of ACK.

For each ACK, pbuf_alloc() is called, with pbuf flag as PBUF_RAM => mem_malloc is called, imagine at this point we have a TX Done interrupt, as no SYS_ARCH_PROTECT(lev) was called, the task is interrupted

TX Done Interrupt :
we call pbuf_free(p) in our interrupt handler, which in turn call mem_free and cause our problem because we end up with inconsistencies with Heap management. Typically this fire an ASSERT in a subsequent mem.c function.

In the source code, you can see that there was some protection in the form of sys_sem_wait/sys_sem_signal, but as previously mentioned, we don't use OS Primitives.

The solution of this problem, once found was simply to add SYS_ARCH_PROTECT protection mechanism as an alternative to sys_sem_xxx function already present. The generic form is :


I want to have your advice to known if it's something that must be corrected (I believe so), or left as is.

lwip-users mailing list

reply via email to

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