Is there a way to find leaked memory using a core file?

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.

---

Memory leak can be be evaluated with core dump as given by paxdiablo. Also if some pattern is repeated in corefile then it can evaluated as given below: 1. I have taken a sample c++ example:

class Base  
{  
    public:  
    virtual void fun(){}  
    virtual void xyz(){}  
    virtual void lmv(){}  
    virtual void abc(){}  
};  

class Derived: public Base  
{  
    public:  
    void fun(){}  
    void xyz(){}  
    void lmv(){}  
     void abc(){}  
};  

void fun()  
{  
    Base *obj  = new Derived();  
}  
int main()  
{  
    for(int i=0; i<2500;i++)  
    fun();  
    sleep(3600);  
    return 0; 
}

2. Created a core with gcore command

3. Search the repeated pattern from core file. ayadav@ajay-PC:~$ hexdump core.10639 | awk '{printf "%s%s%s%s\n%s%s%s%s\n", $5,$4,$3,$2,$9,$8,$7,$6}' | sort | uniq -c | sort -nr | head 6685 0000000000000000
   2502 0000002100000000
   2500 004008d000000000
   726 0000000000007eff
   502
   125 2e4314d000007eff
   93 006010d000000000
   81 0000000100007eff
   80 0000000100000000
   73 0000000000000001

0000002100000000 and 004008d000000000 are repeated pattern

4. Check each qword is what with? (gdb) info symbol ... (gdb) x ...

   example
   (gdb) info symbol 0x4008d000
   No symbol matches 0x4008d000.
   (gdb) info symbol 0x4008d0
   vtable for Derived + 16 in section .rodata of /home/ayadav/virtual

5. Probably most frequent vtable must relate to memory leak i.e Derived vtable.

Note: I agree coredump analysis is not best practice to find memory leak. Memory leak can be find with different static and dynamic tools like valgrind etc.

---

As paxdiablo has said, it is hardly feasible to find out what leaked just by looking at heap (malloc) data structures post-mortem.

One fairly light way to find out what type of objects is leaking is to have an instance counter for each class that may leak. This way you could just examine the instance counters in the core file.