Freertos stm32 : malloc and free assert

Kernel
1

hemant2007 wrote on Tuesday, January 24, 2017:

Hi all,
i am using freertos on stm32 uc. I am using heap4.c. Heap allocated is 40kB. I get assert in pvmalloc and pvfree functions when they are called from lwip thread. My observation is that after mail box creation or mail box free is called from lwip thread then only these two functions viz pvmalloc and pvfree are giving assert.
Otherwise they work ok. I mean if pvmalloc and pvfree are called from any other location in code they work ok.
I incresed size of heap also but same problem exists.
Can you hint where might be issue?
Do I need to enable any hook ?
or why is happening.
thanks for reading.
Thanks
Hemantraj

2

rtel wrote on Tuesday, January 24, 2017:

Which asserts are being hit? I think in vPortFree() the only assert is
if you pass in a block that has either already been freed (or has not
been freed but the meta data in the block has been corrupted) or is
NULL. Could the memory block be being corrupted?

Do you assert() if pvPortMalloc() fails? If not, do you check the value
returned from pvPortMalloc() before you use it?

3

hemant2007 wrote on Tuesday, January 24, 2017:

Thanks for reply.
In free function, I am getting asset at following
configASSERT( pxLink->pxNextFreeBlock == NULL );

4

rtel wrote on Tuesday, January 24, 2017:

That would indicate the block being freed is not valid either because it has already been freed, it was never allocated in the first place, or it has been corrupted.


5

hemant2007 wrote on Tuesday, January 24, 2017:

Also,
Could the memory block be being corrupted?
I earlier thought this may be problem so I have shifted location of heap allocated on RAM to other unused space. But still I am having same problem.

Are there some more was to confirm on this?

Thanks for your reply.

6

hemant2007 wrote on Tuesday, January 24, 2017:

Next,
Do you assert() if pvPortMalloc() fails? If not, do you check the value
returned from pvPortMalloc() before you use it?

I have written malloc fail hook but it is not asserted there. That is malloc never returns NULL

7

hemant2007 wrote on Tuesday, January 24, 2017:

Also sometimes in malloc I get assert on following,
/* This block is to be split into two. Create a new
block following the number of bytes requested. The void
cast is used to prevent byte alignment warnings from the
compiler. */
pxNewBlockLink = ( void * ) ( ( ( uint8_t * ) pxBlock ) + xWantedSize );
configASSERT( ( ( ( uint32_t ) pxNewBlockLink ) & portBYTE_ALIGNMENT_MASK ) == 0 );

8

hemant2007 wrote on Monday, January 30, 2017:

As I am getting assert at
configASSERT( pxLink->pxNextFreeBlock == NULL )
for which you have given following comments,
That would indicate the block being freed is not valid either because it has already been freed, it was never allocated in the first place, or it has been corrupted

How to debug this further?

9

rtel wrote on Monday, January 30, 2017:

When the block is allocated pxLink->pxNextFreeBlock is set to NULL. If
you debugger is capable, after pxLink->pxNextFreeBlock has been set to
NULL put a data watchpoint on pxLink->pxNextFreeBlock so the MCU stops
when it gets written to. Then you should see what is writing over it.

10

hemant2007 wrote on Wednesday, February 01, 2017:

thanks for reply,
I have one more question,
I now get assert at following statement in pvmalloc
configASSERT( ( ( ( uint32_t ) pxNewBlockLink ) & portBYTE_ALIGNMENT_MASK ) == 0 );

can u explain?
I have recently increased stack size of task from 128 to 512.

11

hemant2007 wrote on Wednesday, February 01, 2017:

Hello…
Can we discuss?

12

hemant2007 wrote on Wednesday, February 01, 2017:

I am having same issue as discussed,
https://sourceforge.net/p/freertos/discussion/382005/thread/ba211d48/

13

rtel wrote on Wednesday, February 01, 2017:

I think that thread was concluded as a memory leak in the application.

You can track memory allocation and frees using the FreeRTOS+Trace tool.

14

rtel wrote on Wednesday, February 01, 2017:

That assert should either happen the first time you call the function,
or not at all. Is it happening on the first allocation? If not, it
again shows that the data structures have been corrupted.