I have a core dump from an application with a memory leak. I have used the strings command and xdd to examine the file and I’ve got a few ideas of which part of the program might be responsible for the leak. I’m able to run up the core file in gdb with the application but I can’t do a lot of testing with it because it’s an embedded application with lots of complex time based I/O which I can’t simulate in the office.
I’ve also heard that running with various memory leak detection utilities will slow down the app which we can’t afford because it is running at near CPU capacity already.
So for now, all I have is this core file. Example of what I’m looking for: Is there a pointer table I can examine to find memory that’s been allocated which I can then use to try and find stuff that should have been freed but hasn’t been?
Not very easily, no. The whole point of leaked memory is that it’s memory that was allocated that no longer has a reference to it.
You would have to walk through the entire memory arena to get a list of all allocated blocks, then examine every possible variable/memory-location which may be pointing to it (with almost certainly some false positives).
It may be worth a shot getting some statistics on the allocated blocks. Assuming that your memory leak is causing an out-of-memory problem, most of the blocks would be of a specific type, based on possibly size or the content.
For example, if 80% of the allocated blocks are 31424 bytes long, you’d be looking for allocations of that range (give or take 16 bytes, depending on how the memory allocator works).
Or, if they all contain strings like “2011-01-01 15:25:00 Beginning process 42”, you may want to look for the leak in the logging library.
In any case, you will have to dive into the C++ runtime source code to find out how to locate the memory arena, then use that code to be able to traverse the structures.