malloc() confusion

[Neilp]

Hi all.
I hope someone can explain to me why this happens. I was having weird behaviour with malloc in a project, so I wrote a simple test program to play with malloc and I found a strange problem. (see code below). In the first loop, nothing is previously allocated, and every attempt at malloc() passes (does not return NULL). The I make an allocation from the heap with pBlock = malloc(8); and re-run the test loop. Now, most of the attempts at malloc fail, with only 8 passes while z is in the range of 5 to 12. Can anyone explain to me why this is happening.

I am using Codewarrior development studio for Coldfire, special edition V7.0 build 15

Regards,
Neil.

Code:

//#include <stdlib.h>/*Including used modules for compiling procedure*/#include "Cpu.h"/*Include shared modules, which are used for whole project*/#include "PE_Types.h"#include "PE_Error.h"#include "PE_Const.h"#include "IO_Map.h"uint8* pTest;uint8* pBlock;uint8 x,y,z,a;uint16 pass,fail;void main(void){  /*** Processor Expert internal initialization. DON'T REMOVE THIS CODE!!! ***/  PE_low_level_init();  /*** End of Processor Expert internal initialization.                    ***/x=0;y=0;pass = 0;fail = 0;//// Here, nothing is already allocated//for(z=1; z<250; z++) { pTest = malloc(z); if(pTest == NULL)  ++fail; else  {  ++pass;  free(pTest);  } } //Here, every attemp at malloc passedpBlock = malloc(8); //Here, we allocate another block of heappass=0;fail=0; for(z=1; z<250; z++) { pTest = malloc(z); if(pTest == NULL)  ++fail; else  {  ++pass;  free(pTest);  } }  for(;;) {}} //Here, we only had 8 attempts at malloc pass, whith z = 5-12  //The rest of the attempts failed./* END Project */

 

[Neilp]

(quote)
You could recompile msl with _MSL_USE_FIX_MALLOC_POOLS set to 0 and that would achieve your goal.(quote)

Thanks Rich your a genius. I recompiled alloc.c with _MSL_USE_FIX_MALLOC_POOLS set to 0 and now it works. I'll try it in the real application tomorrow.

Thanks again.
Neil.

[RichTestardi]

I think you're being bit by fixed memory pools (hogging all your memory) -- check out this thread:

http://forums.freescale.com/freescale/board/message?board.id=CWCFCOMM&thread.id=2006

-- Rich

[RichTestardi]

And I'll just copy the salient information here:

--- snip ---

I think the real problem is your use of "fixed" memory pools...

You could recompile msl with _MSL_USE_FIX_MALLOC_POOLS set to 0 and that would achieve your goal.  I'm sure someone here can tell you how to do that (I don't use msl).  Unfortunately, max_fix_pool_size is a constant, so I think a recompile of msl is required.

I believe the real problem is that each fixed pool uses 4k of memory...  And there are *5* fixed pool sizes!  You have your heap set to 4k total!  So the first pool size you allocate (8 bytes) succeeds, and the second one (16 bytes) fails.

Fixed pools make no sense on a processor with 32k of total memory.

From the MSL C Reference:

_MSL_USE_FIX_MALLOC_POOLS For tiny allocations, fixed sized pools help

significantly speed allocation/deallocation, used

only with the modern memory pooling scheme.

You can reserve a pool for a small range of

sizes. The use of fixed sized pools can be

disabled by setting

_MSL_USE_FIX_MALLOC_POOLS to 0. The

default value is 1. Use of fixed size pools

requires further configuration. The current

shipping configuration is:

1. Each pool will handle approximately 4000

bytes worth of requests before asking for more

memory.

2. There are 4 pool types. Each type is

responsible for a different range of requests:

a. 0 - 12 bytes

b. 13 - 20 bytes

c. 21 - 36 bytes

d. 37 - 68 bytes

Requests for greater than 68 bytes go to the

variable size pools. The number of types of pools

is configurable below. The range of requests for

each type is also configurable.

[Neilp]

Hi Jim.

No, I get the same result, all attempts at malloc(z) fail except where z = 5-12.
Some more Info: In the first loop, malloc(z) returns 0x20002DEC from z = 1-67, then returns 0x20002DD4 for the rest of the loop. When pBlock is allocated, it grabs 0x20002DEC. The the second loop returns 0 (NULL), except when z = 5-12, then 0x20002DFC is returned.

Neil.

[Neilp]

Oh, by the by, I am running the code on a M5211DEMO board in ram. I have already tried running it from flash too, and the result is the same. Don't know if this is important.

Neil.

[JimDon]

Just wondering, what if you put the the

pBlock = malloc(8); //Here, we allocate another block of heap

before the first 'for' loop. I'm thinking some kind of strange fragmention issue.