heap_4.c , strange behaviour , heap fragmentation ?

mmelamud wrote on Thursday, October 17, 2013:

Hi all ,

I am experiencing some weird behavior when using heap_4.c , i have allocated 1.5 megabyte of RAM for the usage of heap_4 , so i should have plenty of memory to use .

After some time ( and many allocations that have been made ) , all of a sudden the program gets stuck in infinite loop in the function called :

static void QA_prvInsertBlockIntoFreeList( QA_xBlockLink *pxBlockToInsert )

And the infinite loop is here :

/* Iterate through the list until a block is found that has a higher address
than the block being inserted. */

for( pxIterator = &QA_xStart; pxIterator->pxNextFreeBlock < pxBlockToInsert; pxIterator = pxIterator->pxNextFreeBlock )
{
/* Nothing to do here, just iterate to the right position. */
}

Could any one can tell me why this occur? is it some kind of memory fragmentation ?

Thanks
Michael

rtel wrote on Thursday, October 17, 2013:

heap_4 shouldn’t fragment, and even if it did, it should just return NULL if it can’t find a block large enough - definitely not just loop around indefinitely.

This looks like just a data corruption so the linked list structures are not consistent. Is it possible you freed a block of memory that was either itself corrupt (there is a hidden structure before the memory usable by the application), had not been allocated by heap_4, or had already been freed? If you are using an up to date FreeRTOS version and have configASSERT() defined, then all those potential issues should be trapped.

From the variable names it looks like this is not unmodified FreeRTOS code - did you make many edits?

Regards.

mmelamud wrote on Thursday, October 17, 2013:

No edits what so ever , i just renamed the variables , because i am using two different heaps , one for The OS , and the second one is for my routine logic

I will check the configASSERT to see if its enabled , and you right it does looks like a corruption of some kind.