4

I have looked through GDB documentation, but haven't found anything that works or shows what I need: the maximum amount of memory that is used by my application.

I'm using MinGW-w64 (GCC for Windows) if that's relevant. I'd like something programmatically, not "look in your task manager". Also: my application executes in one go, it doesn't stop or halt anywhere, and I'd like to keep it that way.

Thanks!

Improve this question
4
  • Does the approach need to be portable? Commented Feb 5, 2011 at 12:25
  • 1
    Would WMI be an option for you? It could certainly tell you almost anything you need about any process: msdn.microsoft.com/en-us/library/aa394582(v=vs.85).aspx Commented Feb 5, 2011 at 12:26
  • @bdonlan: Well, I'm kind of surprised gdb doesn't have the capability to sum up the amount... Portable would be better, and external to the application itself would be preferred (no source code contamination). @alex: That's a bit heavy for a simple number of MBs, no? And I'd like to have a existing app report this, so I don't have to screw around with my own implementation. Commented Feb 5, 2011 at 12:40
  • Check out this question: stackoverflow.com/questions/413477/… Commented Feb 5, 2011 at 14:52

3 Answers 3

Reset to default
1

You could wrap malloc/free or new/delete: How-to-profile-memory-usage-of-a-c-program

Thereby you can check how much memory (heap) you are using at any time.

Improve this answer
Sign up to request clarification or add additional context in comments.

1 Comment

Agreed. Just define your own that gets a integer pointer parameter to count memory usage.
0

Windows provides functions to return how much memory is being used.

http://msdn.microsoft.com/en-us/library/aa366589(v=VS.85).aspx

Improve this answer

2 Comments

These don't seem to report application memory usages, only system totals.
Check the ullAvailVirtual and ullTotalVirtual members.
0

The standard doesn't specify anything deeper than malloc() and free(), which leaves C libraries free to implement them to work in their target environments. The result is that a debugger like GDB that isn't tied to a specific environment will have no insight into memory allocation.

Improve this answer

2 Comments

But surely the OS knows what resources are tied to a specific resource, and GDB can control the execution of a program to the combined effect of monitoring these resources? Or do I want too much?
The short answer is that understanding how a process manages its memory management is not GDB's bailiwick and the reasons why could be the subject of a very long article. When GDB wants to allocate memory in the process being debugged (which it does), it calls whatever allocator is linked into it and doesn't care about what happens inside. Total memory is allocated isn't really a debugging function; it's something the OS has to worry about.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.