Checking for memory leaks in a running program

Question

I have a question out of curiosity relating to checking for memory leaks.

Being someone who has used valgrind frequently to check for memory leaks in my code for the last year or two, I suddenly came to think that it only detects lost/unfreed memory after the life of the program.

So, in light of that, I was thinking that if you have a long-running program which malloc()'s intermittently and doesn't free() until the application exits, then the potential to eat memory (not necessarily through leaks) is huge and isn't observable using these tools because they only check after the programs lifetime. Are there GDB-like tools which can stop an application while running and check for memory which is and isn't referenced at an instance in the life of the application?

Answer 1

Are there GDB-like tools which can stop an application while running and check for memory which is and isn't referenced at an instance in the life of the application?

Yes: Valgrind.

Specifically, the SVN version of Valgrind has a gdbserver stub embedded into it.

This allows you to do all kinds of cool debugging, not possible before:

• You can run program under valgrind and have GDB breakpoints at the same time
• You can ask valgrind: is this memory allocated? was this variable initialized?
• You can ask valgrind: what new leaks happened since last time I asked for leaks?

I think you can also ask it to list not-leaked new allocations.

Answer 2

What I have done, which was not a tool, for a long-running socket-based server, was to do an operation, but before that print out the amount of free memory, then print it out after my operation, and see if there was any difference.

I knew that in theory my server should have returned all memory used on each call to the server, so if I was the only one calling it, it shouldn't use much more memory than when it started.

You may find that some memory was needed on the first call, so you may want to make several calls, so everything is initialized, then you can do checks like this.

The other option is to create a list of all memory you are mallocing, then when you free it delete from the list that node, and at the end, see which ones still haven't been freed.