freeMemory Inaccurate?

Troubleshooting
1

I'm trying to use freeMemory to keep track of what I have free, and also to catch leaks and bugs. I've noticed however, that after allocating an array of objects, the memory only changes in specific places, and also that after deleting that array, the memory reported by freeMemory doesn't change. I'm not sure If I can actually trust this method.

EDIT:

Description from Firmware Docs:

Retrieves the amount of memory guaranteed to be available. The actual amount of free memory will be at least as large as the value returned.

I noticed that the number given by freeMemory() never actually increases. And that, in my initial allocation, memory decreases regularly, and then in subsequent allocations, it appears to stay the same. This is leading me to believe that freeMemory() operates on some sort of counter, where it just decrements for allocated memory and never actually increases. It just tells you how much memory you've Never used, not how much memory you're currently not using.

Can anyone substantiate or refute my claims?

2

when you compile the program the compiler allocates memory used for an an array, as in it sets aside that amount of memory that WILL be used by the array, even if you delete the contents of the array that amount of memory is STILL set aside to store that array.

3

Just like it says in the docs - the amount of free memory may be more. This is because of how the memory allocator works, the free memory value can decrease, but never increase, even though there is more free memory.

2 Likes
4

So, is this to say that I am right. The amount of memory reported by freeMemory() is the memory that has not been used by the program yet. Freed memory does not get added back ever?

5

The freeMemory represents the highest point that memory has been allocated. When memory is freed, that high-point doesn’t change (but the memory is still freed and available for re-allocation.)

6

This is news to me.

Can we please also get an access method that returns the true, instantaneous, size of the free pool, and not just the low-water mark ?

7

That’s not possible - the runtime doesn’t provide this information.

8

Darn - which memory allocator do we use ? From memory (see what I did there ?) they were called something like heap-< n >

9

we are using malloc/free. The freeMemory() is the different between the top of heap and the bottom of the stack.

10

I found the reference I was thinking of - I was wondering which of these we use (away from my firmware/* tree at present…)

11

we use heap3.c which delegates to malloc/free.

1 Like
12

Is there a second pool (populated by things that have been free()'ed) - since once you _sbrk() it is owned by malloc()/free() ?

If so, isn’t the instantaneous free memory the sum of that and space left for _sbrk() ?

13

We’d have to walk the heap to find all the objects in use and subtract that from the current heap size. This involves digging into the internals of ARM gcc malloc implementation than there is time for.

1 Like
14

Is it this one?

selected here:

just asking because the path says election and I wonder if that still applies for the photon.

15

It’s embedded inside the WICED SDK. System.freeMemory() has been made more accurate for the 0.4.9 release.

16

any news on 0.4.9 , which was said to be out today ?