[Memory management] Multiple malloc/free alignment fragmentation issues

benoitdes wrote on Wednesday, March 04, 2015:

Hi everyone,

I’m working on a project on an STM32F4 with FreeRtos 8.2.0. My program malloc and Free a lot of little structures (i know this possibly leads to fragmentation but i don’t really have the choice) and i use heap 4.

I use xPortGetFreeHeapSize() to monitor my memory allocated in my heap. On the side i have done a trace tool which trace all malloc and free actions (i’m aware that the length of the objects doesn’t take in account the extra data added in freertos malloc).

       TYPE  SIZE
MALLOC TSD   20
MALLOC OFL   8
MALLOC PAT   8
FREE   OFL   8

MALLOC CUR   16
MALLOC OFL   8
MALLOC LOE   8
FREE   OFL   8

MALLOC OFL   8
FREE   TSD   20
FREE   PAT   8
FREE   LOE   8

FREE   OFL   8
MALLOC OFL   8
FREE   CUR   16
FREE   OFL   8

Sum_Malloc - Sum_Free = 0 but when i monitor with xPortGetFreeHeapSize the first time i perform this action, 8 byte are still present and the second time it returns to 0 and so forth and so on.

When i perform a lot of this kind of actions it fills all the memory slowly. This is what really bother me…

Do you think it is an alignement issue ? I’m not thinking about fragmentation because if i understand well xPortGetFreeHeapSize can’t monitor it.

more generally do you think that i should use the heap 5 to use it’s ability to span data or should i allocate areas in ram in order to store all the same size structures in the same areas ?
Do you have other ideas ?
One more thing i can’t know in advance how much of each structures will be created that’s why everything is malloced dynamicaly.

Thanks in advance for your help !

rtel wrote on Wednesday, March 04, 2015:

I’m not fully following your post.

Are you saying allocating and freeing lots of small blocks causes memory to leak - so eventually an attempt to allocate a small block will fail even though there should be heap space available?

Do you have configASSERT() defined?

Switching to heap_5 will not make a difference for you, heap_4 and heap_5 use the same algorithm.

Regards.

benoitdes wrote on Thursday, March 05, 2015:

Hi,

Yes this is what i mean. Sometimes FreeRTOS keeps in it’s memory counter something or part of something already Freed. This seems to fill slowly the heap whereas there is still places available. Of course this happens only sometimes as for example the Allocations listed above.

I have configAssert defined and i’m trying to find something clearer.

rtel wrote on Thursday, March 05, 2015:

I just set up a test that allocated and freed block in exactly the
sequence you set out in your first post - printing out the free bytes
remaining as it went. The free bytes remaining at the end (after all
the blocks had been freed) was equal to the free bytes at the start
(before any bytes had been allocated).

The output is below:

Free bytes remaining = 23880
Allocating TSD 20
Free bytes remaining = 23852
Allocating OFL 8
Free bytes remaining = 23836
Allocating PAT 8
Free bytes remaining = 23820
Freeing OFL 8
Free bytes remaining = 23836
Allocating CUR 16
Free bytes remaining = 23812
Allocating OFL 8
Free bytes remaining = 23796
Allocating LOE 8
Free bytes remaining = 23780
Freeing OFL 8
Free bytes remaining = 23796
Allocating OFL 8
Free bytes remaining = 23780
Freeing TSD 20
Free bytes remaining = 23808
Freeing PAT 8
Free bytes remaining = 23824
Freeing LOE 8
Free bytes remaining = 23840
Freeing OFL 8
Free bytes remaining = 23856
Allocating OFL 8
Free bytes remaining = 23840
Freeing CUR 16
Free bytes remaining = 23864
Freeing OFL 8
Free bytes remaining = 23880

It starts and ends with 23880 bytes remaining.

Regards.

benoitdes wrote on Friday, March 06, 2015:

I finaly found my bug, of course it was my fault, thanks a lot for your support.

Regards,