pvPortMalloc blocking at configassert of splitting the block into two blocks

Libraries
1

I am facing a strange issue where the malloc search for a block that is having free space than the wanted size but after 4 successful malloc allocations the the xstart.pxnextfreeblock is pointing to 0xffffffff(pxBlock = xStart.pxNextFreeBlock;) and it is having size of some junk value and is trying to get allocated and after that it is going to config assert check where the block is not aligned as per requirements
configASSERT( ( ( ( size_t ) pxNewBlockLink ) & portBYTE_ALIGNMENT_MASK ) == 0 );
Thanks for your time.

2

It would help a lot, if you add the required information at the 1st place.:
Which FreeRTOS version, the selected heap variant, corresponding FreeRTOSConfig.h items, etc.

3

Sorry I forgot to add it. I am using heap4.

4

My first guess would be something that is using an allocated block is writing outside the block it has gotten, and corrupting the structure of the heap.

1 Like
5

no, by the time I am getting this error it is still allocating and nothing is being performed on any allocated block.

6

That seems like a memory corruption - would you please try to find when xStart.pxNextFreeBlock gets set to 0xffffffff. You can try to put a data breakpoint on xStart.pxNextFreeBlock to catch when it gets updated unexpectedly.

Thanks.

7

what I have observed is after 4 or 5 allocations the next block of xStart is 0x00. And next time it is pointing to memfaulthandler address of nvic and freebytesize of almost 4 lakh

8

Because of the “end marker”,xStart.pxNextFreeBlock should never be NULL: https://github.com/FreeRTOS/FreeRTOS-Kernel/blob/master/portable/MemMang/heap_4.c#L359

If it is after 4-5 allocations, it should be relatively easy to put a data breakpoint. Put a data breakpoint for xStart.pxNextFreeBlock changes. It will cause the program to break in debugger whenever xStart.pxNextFreeBlock changes. You can then examine the callstack to see if it is a legitimate change or a memory corruption.

Thanks.