AnsweredAssumed Answered

curious malloc behaviour

Question asked by Paso on Feb 27, 2010
Latest reply on Mar 2, 2010 by CraigG

We had some heap fragmentation issues in our real app.

 

We simplified our problem down to this:

 

- Suppose you defined a 0x18000 bytes heap.

- Starting from empty heap, right adter main(), just a simple sequence like:

 

p = malloc(0x10000);

free(p);

p = malloc(0x11000); 

assert(p);

 

will fail.

 

 

Seems that "coalescing" empty heap blocks works only for previously allocated blocks; i.e., it doens't look at remaining empty unused heap bytes for merging. I undestand this is not a bug, but a consequence of heap management algorithm, but neverteless this behaviour seems odd, at first glance.

 

An easy fix is to allocate and deallocate, once, the whole available heap (minus a little housekeeping margin) just in the beginning.

 

This put the whole heap space "in control" of the free block list, so when asking for the 0x11000 block the heap manager will be able to use (merging) also the remaining 0x8000 bytes, left unused by the first malloc.

 

We were just curious on why this behaviour has been choosen... any idea ?

 

We attach a simple project, for VDSP 5.0 Update 7; works also in simulation.

Attachments

Outcomes