A problem with freeing allocated memory

[lcl]

Hi!

So I'm allocating arrays of pointers, which looks and can be used like 2D arrays.
I have no problems allocating the memory, but freeing it just doesn't seem to happen.
I can see from task manager, that when I call the allocation functions, the amount of memory used by the game grows.
But when it should free the same amount of memory, nothing happens in task manager, it shows the exact same amount of memory being used by the game.
Is this a bug with Game Editor, or am I freeing the memory in a wrong way?

Here are the functions used for allocation and freeing of the memory.

Code: Select all

int ** array2D;

int allocate2Darray(int rows, int cols)
{
    int i, success = 1;
 
    array2D = malloc(rows * sizeof(int *));
 
    if (array2D)
    {
        for (i = 0; i < rows; i ++)
        {
            array2D[i] = malloc(cols * sizeof(int));
            if (!array2D)success = 0;
        }
    }
    else success = 0;
 
    return success;
}

void free2Darray(int rows)
{
    int i;
 
    for (i = 0; i < rows; i ++)
    {
        free(array2D[i]);
    }
 
    free(array2D);
}


[skydereign]

Sorry for the late reply. Using that same code works fine for me. If it is not freeing anything at all the only thing I can think of is the free call is not being run.

[lcl]

Thanks for replying.

Now that I did some more testing, I agree with you.
The problem has to be somewhere else. I did a simple test with the above codes and it works as it should.
It appears that when a game made with Game Editor allocates memory, it doesn't get actually freed for other programs to use before the game is closed.
But calling free frees the memory for the game to use. And now calling malloc will only allocate new memory for the game if the previously allocated, then freed memory isn't enough.

So the actual problems with my game crashing on allocating and freeing memory must be caused by the game trying to access values that are not allocated or something similar to that.
Thanks to you, I've now narrowed down one possible reason for the crashes.

[Zivouhr]

Does memory freeing relate to RAM being used by the game, I"m guessing?
Would too much memory cause a game to slow down in frame rate?
Interesting topic I have much to learn about.

[bat78]

It is not too late for you to learn.
#define dma malloc, calloc, realloc

Functions for memory-management provided by stdlib.h are rather specific. They invoke operations of expanding the heap. Heap is part of the RAM, so as many other instances, independently of them being a read-only memory or not. One application can not access exactly the same memory that another application uses.. that's why there is the notion "Virtual Memory". Every process runs in its own virtual memory. In order to access such a memory, you can perform IPC or (Inter-Process Communication), communication through the processes's memories with memory-mapped i/o, but it is complex and it requires the unforgivable keg of wisdom.

Your problem must be caused by the "UFB Event" or Event caused by the function's undefined behavior. In this case the UB is not literal it is just that we don't know how the function behaves. In simpler words, dma are smart functions that doesn't always just "allocate" memory for us.
If you are allocating a small amount of bytes, dma will most likely find the best place in the heap, that will be dedicated for the data.
However if you are allocating more bytes, these functions might need to expand the heap, which means they have to proceed more operations, which means the application will slow down.

When a call of free has been parsed, the free is just as smart as dma and it may or may not give back that memory available to the OS, but to another call of dma. It will not shrink back the heap. This is very dangerous task after all, especially if you have a lot of timely memory i/o.

Conclusion you can't rely on free shrinking the heap, therefore the amount of RAM consumed by the whole application may stay still.
As for the speed, data saved on stack (statically allocated) will be much faster accessed, because the program will just decrement the stack pointer.