Checking for memory leaks in a running program

问题:

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?

回答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.

回答2:

That is not generally possible in a language that supports pointer arithmetic, since for example - you could cast an pointer to an integer and back. See http://www.cs.umd.edu/class/sum2003/cmsc311/Notes/BitOp/pointer.html

回答3:

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.

回答4:

Leaked memory is defined as memory that is not referenced by anything in the program.

If you malloced memory and somewhere in your data there is a pointer pointing to that memory it isn't "lost" as far as any automatic check can now.

However, if you allocated memory, never free'ed it but you don't have any pointer pointing to it you have most likely leaked that memory - as there is no way for you to reference it.

Programs like valgrind can find leaks of the kind described above (lost of reference). AFAIK nothing can find "logical" leaks where you still hold a reference to the memory.