CODEWITHSUNDEEP
c++gdbvalgrindtotalview
suresh
suresh

Reputation: 115

Finding memory consumed using core file

I am analysing high memory consumption problem in our software. I have a core file corresponding to this high memory consumption(this core file is generated by killing our application which generates core file). But I am not able to view the actual memory consumption using this core file. I used Totalview and gdb...using these two I am not getting a snapshot of the total memory consumed by my process and which library is eating up all the memory.

This memory consumption is hitting us over 10 to 20 days of time and hence I am trying to find out what has caused this high memory consumption.

Can valgrind help me in analysing this core file?

Any input/suggestion is highly appreciated.

Upvotes: 0

Views: 975

Answers (1)

Chris Gottbrath
Chris Gottbrath

Reputation: 216

@suresh,

Hi, I'm the product manager for TotalView at Rogue Wave Software.

Can you describe the scenario a bit more? Is the program running along with "normal memory consumption" for a long time and then suddenly the memory consumption goes through the roof? Or is the program slowly and steadily consuming memory till it exhausts available resources?

When it is crashing is it crashing because it literally runs out of memory or are you killing it because it has started swapping and being unresponsive?

In general I'd recommend running it under MemoryScape (in TotalView or the Standalone version) and when it starts to show unexpected memory consumption you want to pause it and run a memory leak report. It is likely that this will point right to the problem.

It is possible that the memory use isn't a "classical" leak because you still have pointers referencing the data -- but you are simply over-allocating. In this case you won't see anything on the leak report, but you may be able to pick out which allocation is "gone bad" by watching which allocations are growing. There are a number of ways to do this.

  1. Pause periodically and note how the heap usage breaks down in the Heap Status Source Code report. For example you may note that the number of allocations associated with a specific source code file just keeps increasing.

  2. If you are using TotalView you can use the "set heap baseline" functionality when the program seems be behaving well then filter against this baseline. Again you may want to use the source code report (though the graphical or backtrace reports support filtering too).

  3. Or you can use the "export memory data" feature to store an image of what the "normal" heap status is. This creates a binary heap status file. Then let the program run till you get into the state where your program has high memory consumption. At that point you pause your live app, load the stored heap data file and you can do a comparison.

Wow, this is getting long. One final thought. You said you are getting core files. Under the debugger you should get a chance to examine the running program before it gets cleaned up. If this doesn't happen let me know. If you really want to work via core files (for example, this is happening in a production environment and you don't want to run the debugger there) let us know -- there are techniques where we can instrument the application using the HIA and then enable you to do offline analysis of your heap status.

Good luck!

Chris Gotbrath

Principal Product Manager for TotalView and ThreadSpotter, Rogue Wave Software

email: first . last at roguewave . com

Upvotes: 0

Related Questions