vicui wrote on Saturday, August 23, 2014:
Hi:
I use LPCXPRESSO IDE to develop a simple web server on LPC1769, Freertos use HEAP3.c to use system malloc and free funtion. the web server can refresh per 3 second by itself, it works well. but if I refresh it by press F5 frequencty, FreeRTOS reports “DIE:ERROR:FREERTOS: malloc failure !”.
any problem on it ?
vicui wrote on Saturday, August 23, 2014:
I also enable use C lib 's malloc and free
//#define MEM_LIBC_MALLOC 1
//#define MEMP_MEM_MALLOC 1
I think lwip can’t free memory on time in more request coming … it cause malloc fail .
but how to fix ? add protect in application ?
vicui wrote on Saturday, August 23, 2014:
by add unsigned int __check_heap_overflow (void * new_end_of_heap)
{
unsigned long stackend = ((unsigned long) &_vStackTop) - STACK_SIZE;
return ((unsigned long)new_end_of_heap >= stackend);
}
I found that the heap is really overflow once more request incoming. in real application, Freertos use malloc, LWIP also use malloc. so, how to fix the problem ? adding delay time is not a good solution
edwards3 wrote on Saturday, August 23, 2014:
Just sounds like you are leaking memory somewhere, probably in lwIP port.
vicui wrote on Saturday, August 23, 2014:
NXP release more version on the LPC1769 demo web server, I try KEIL and LPCXPRESSO, both has the same issue. I don’t think LWIP porting has problem. otherwise, the demo server can’t refresh itself per 3 seconds for long time.
rtel wrote on Saturday, August 23, 2014:
So these are demos you are obtaining from NXP rather than from us?
Regards.
vicui wrote on Saturday, August 23, 2014:
NXP demo is with freertros and lwip. your demo is only for freertos. the issue is only for freertos and lwip. I think the issue is from lwip application, not freertos. I wonder to know how to keep heap safe if freertos and lwip both use C LIB malloc and free.
edwards3 wrote on Saturday, August 23, 2014:
Is the ethernet driver calling free() from an interrupt? Lots of people do that in lwIP without setting the special lwIP constant that tries to make it safe. If it is freeing from an interrupt that is probably the cause.
richard_damon wrote on Sunday, August 24, 2014:
I am not familiar with this implementation as I haven’t used it, but malloc/free is naturally not thread safe. It is possible to make them thread safe by just disabling interrupts inside them, but this gives lousy interrupt response latency (but will let you use them in interrupts). Some implementations allow you to define a way for malloc to use some form of mutex to make it thread safe. If not, you need to do what FreeRTOS does and use a wrapper, and then everyone needs to use that wrapper.