Why this code is not causing memory leak?

Question

I wanted to simulate memory leak in my application. I write following code, and tried to see in perfmon.

int main()
{
    int *i;
    while(1)
    {

        i = (int *) malloc(1000);

        //just to avoid lazy allocation
        *i = 100;

        if(i == NULL)
        {
            printf("Memory Not Allocated\n");
        }

        Sleep(1000);
    }
}

When I see used memory in Task Manager, it is fluctuate between 52K and 136K, but not going beyond that. Means, somethings it shows 52K and sometimes 136K, I do not understand how this code once goes to 136K, coming back to 52K, and not going beyond that.

I tried to use perfmon, but not able to exactly what to see in perfmon, snapshot of counters, enter image description here

Please suggest how to simulate memory leak and how to detect it.

Put a check when you allocate memory to see if it actually gets allocated. — brokenfoot, Mar 13 '14 at 03:31
You allocate just 100 bytes per 10 seconds. It takes over 6 minutes to allocate a full 4k page. Try using bigger numbers. — aragaer, Mar 13 '14 at 03:37
Windows uses lazy allocation, it may not actually allocate memory until the memory is used. And 100 bytes sure isn't going to show up in Task Manager, try allocating a whole lot more. — M.M, Mar 13 '14 at 03:38
The reason it doesnt go beyond a certain limit is because there's a limit on the size of heap that can be allocated. Once you reach that size, it'll start returning NULL. I am not sure why it shows you that the size is decreasing. — brokenfoot, Mar 13 '14 at 03:38
Leaking 100 bytes every 10 seconds is going to take ages before anything shows up. — jaket, Mar 13 '14 at 03:40

score 10 · Answer 1 · answered Mar 13 '14 at 05:55

While an OS may defer actual allocation of dynamically allocated memory until it is used, the compiler optimizer may eliminate allocations that are only written to, and never read from. Because your writes have no well defined observable behaviour (you never read from it), the compiler may well optimize it away. I would suggest examing the generated assembly code to see what the compiler is actually generating. Really, this ought be one of the first steps in answering questions like "why doesn't this code behave like I think it should?".

+1. Really nice explanation. Bottom line is, it may not be as easily reproducible in non-real world, as it seems to be. — Pranit Kothari, Mar 13 '14 at 06:17

score 3 · Accepted Answer · answered Mar 13 '14 at 03:46

Strictly, a memory leak is a bit context dependent: something in your program keeps allocating memory over time and not freeing it, when it should have been freed.

You code produces a "leak" on each subsequent pass through the while loop, because your program loses knowledge of a previously allocated pointer at that point. This is only visible by inspection however in this case; from the code posted it looks more like you are actually doing, albeit very slowly, is attempting to create a memory stress situation.

To 'find' a leak without inspection you need to run a tool like valgrind (Unix/Linux/OSX) or in Visual Studio enable allocation tracing with the DEBUG_NEW macro and view the output using a debugger.

If you really want to stress memory in a hurry, allocate 1024 x 1024 x 1024 bytes at a time...

My program is already running on production. I wanted to confirm, if it shows memory leak, because there is performance problem. — Pranit Kothari, Mar 13 '14 at 03:49

Why this code is not causing memory leak?

2 Answers2