Can memory leaks only caused by using the new keyword?

Started by
19 comments, last by Infinisearch 8 years ago

I have a small application which has a memory leak.

To try to find when the memory leaks I overloaded the new operator, however the memory leaked without printing anything to the screen (which I told it to when I overloaded the new operator)

The operator is overloaded like this :


void* operator new(std::size_t sz)
{
    std::cout << "Allocated new memory usng the new operator" << std::endl;
    return std::malloc(sz);
}

So, can memory leaks be caused without the new operator?

If yes, what else could it be caused by? (not sure how many things it could be caused by.....)

Note : I do know that memory leaks are caused by allocating memory and then not deallocating it after.

Answer :

Turns out it was SDL (the game dev library) "who" allocated memory because I didn't close my font after using it.

Advertisement

Memory can also be directly allocated with malloc() or related functions such as realloc() or calloc() or with direct OS calls such as the HeapAlloc() function in Windows.

Memory can also be directly allocated with malloc() or related functions such as realloc() or calloc() or with direct OS calls such as the HeapAlloc() function in Windows.

Alright, then I'm not sure why my code is leaking.

SHouldn't, have checked my code around 20 times now, and I have deallocated all pointers that I use. :/

How have you determined that there is a memory leak?

Memory can also be directly allocated with malloc() or related functions such as realloc() or calloc() or with direct OS calls such as the HeapAlloc() function in Windows.

Alright, then I'm not sure why my code is leaking.

SHouldn't, have checked my code around 20 times now, and I have deallocated all pointers that I use. :/

Are you sure it's your code leaking and not some external library that you're using?

Did you find all the places in your code that you call malloc or one of the other allocation functions? If you never call new then that has to be the cause.

If you are opening Task Manager, and seeing the "memory" usage climb higher, that doesn't automatically mean you have a memory leak. It doesn't mean you don't, but it doesn't mean you do.

Task Manager shows how much memory Windows is making available for your program, not how much memory your program is using.

Some memory managers will also report false positives for global variables located on the stack, which are only released after the program has ended. Objects like std::cout and many other things in the standard library could cause this behaviour.

Don't forget to clean up objects from external libraries as well. I recently fixed one leak of mine because of not cleaning up everything from OpenGL, where I was creating a shader (i.e. 'program'), but forgetting to call 'glDeleteProgram' in the destructor. This caused around 500kb to be leaked everytime this happened.

That's assuming you have made sure it is an actual leak though, because as Servant said, task manager is not reliable for this. You could for instance use the built-in profiler from Visual Studio to view the allocated heap memory, which can give you a very good indication of the location of such leaks.

Memory can also be directly allocated with malloc() or related functions such as realloc() or calloc() or with direct OS calls such as the HeapAlloc() function in Windows.

Alright, then I'm not sure why my code is leaking.

SHouldn't, have checked my code around 20 times now, and I have deallocated all pointers that I use. :/

Are you sure it's your code leaking and not some external library that you're using?

Did you find all the places in your code that you call malloc or one of the other allocation functions? If you never call new then that has to be the cause.

I never use any other keyword except new.

And when my code is leaking it doesn't print anything to the console...

Don't forget to clean up objects from external libraries as well. I recently fixed one leak of mine because of not cleaning up everything from OpenGL, where I was creating a shader (i.e. 'program'), but forgetting to call 'glDeleteProgram' in the destructor. This caused around 500kb to be leaked everytime this happened.

That's assuming you have made sure it is an actual leak though, because as Servant said, task manager is not reliable for this. You could for instance use the built-in profiler from Visual Studio to view the allocated heap memory, which can give you a very good indication of the location of such leaks.

I'm using the memory thing in xcode, which I think should be reliable.

This topic is closed to new replies.

Advertisement