Get C++ Exact Memory Usage

[Josh]

It turns out GetProcessMemoryInfo() is almost useless for debugging. The Windows heap manager allocates chunks of memory at a time, and the results of GetProcessMemoryInfo() mask memory leaks. If you purposely create a leak allocating a little bit of memory at a time in a loop, it won't show up until a certain threshold is reached, and then memory usage will increase by a lot. How can I get the actual memory usage of a C++ program, to detect memory leaks?

[Josh]

Here's what I am looking into now:

http://msdn.microsoft.com/en-us/library/x98tx3cf%28v=vs.80%29.aspx

[Josh]

Jesus, this sucks. I don't want a "tool" to "help" me. I just want to real memory usage!

[wh1sp3r]

http://www.codeproject.com/Articles/9815/Visual-Leak-Detector-Enhanced-Memory-Leak-Detectio

 

I am using it a lot, it will display all memory leaks + call stack, so you know exactly, where leak was found.

[Canardia]

The only accurate way to measure memory consumption in C++, is to make a #ifdef into each class constructor which increases a global memory usage counter, based of sizeof(ClassName), and an #ifdef for the counter itself in the class attributes, and and #ifdef in the destructor to reduce the same amount.

[Josh]

I tried VLD. I added the header and lib paths in Visual Studio, included vld.h, and built the debug version, but nothing happens.

[Josh]

Okay, I got it working. I would still really like to be able to get actual memory usage. :

[Canardia]

With my method you can get the real memory usage, and on all platforms.

[Josh]

This will do it:

http://www.leadwerks.com/werkspace/files/file/352-get-memory-usage

 

With my method you can get the real memory usage, and on all platforms.

That doesn't cover issues like if I allocate a char buffer or something in a function.

[Canardia]

Of course for those cases you have to do the same. Doesn't really make a difference if it's a class or a function.

[Josh]

Memory leaks are based on the assumption the programmer will make errors from time to time. If I could write perfect code, I wouldn't have to test in the first place.

[Guest Red Ocktober]

Memory leaks are based on the assumption the programmer will make errors from time to time.

 

the applications programmer... or the operating systems programmer...

 

... or both?

 

 

--Mike

[Mumbles]

That doesn't cover issues like if I allocate a char buffer or something in a function.

 

Wrap calls to malloc, that's easy

 

As part of what I'm doing:

 

 

// this is the call back for allocation newton memory
void * NewtonMalloc (int sizeInBytes)
{
TotalNewtonAllocated += sizeInBytes;
#ifdef DEBUG_NEWTON_MALLOC
std::cout << "Newton malloc'd " << sizeInBytes << " bytes. (Total: " << TotalNewtonAllocated << ")n";
#endif
return malloc (sizeInBytes);
}

// this is the callback for freeing Newton Memory
void NewtonFree (void * ptr, int sizeInBytes)
{
TotalNewtonAllocated -= sizeInBytes;
#ifdef DEBUG_NEWTON_MALLOC
std::cout << "Newton freed " << sizeInBytes << " bytes. (Remaining: " << TotalNewtonAllocated << ")n";
#endif
free (ptr);
}

 

realloc is more of the same, as is delete. new is a little more complicated though, as you would probably find yourself writing one function per object type, and on top of that, 1 per overloaded constructor. Unless I'm missing something

[Roland]

Maybe some help here ? Personally I would not use malloc/free in C++ if not dealing with some very special memory management code.

 

From http://stackoverflow...and-malloc-free

============

new/delete

• Allocate/release memory
  
  • Memory allocated from 'Free Store'
    
  • Returns a fully typed pointer.
    
  • new (standard version) never returns a NULL (will throw on failure)
    
  • Are called with Type-ID (compiler calculates the size)
    
  • Has a version explicitly to handle arrays.
    
  • Reallocating (to get more space) not handled intuitively (because of copy constructor).
    
  • If they call malloc/free is implementation defined.
    
  • Can add a new memory allocator to deal with low memory (set_new_handler)
    
  • operator new/delete can be overridden legally
    
  • constructor/destructor used to initialize/destroy the object
    

malloc/free

• Allocates/release memory
  
  • Memory allocated from 'Heap'
    
  • Returns a void*
    
  • Returns NULL on failure
    
  • Must specify the size required in bytes.
    
  • Allocating array requires manual calculation of space.
    
  • Reallocating larger chunk of memory simple (No copy constructor to worry about)
    
  • They will NOT call new/delete
    
  • No way to splice user code into the allocation sequence to help with low memory.
    
  • malloc/free can NOT be overridden legally
    

Technically memory allocated by new comes from the 'Free Store' while memory allocated by malloc comes from the 'Heap'. Whether these two areas are the same is an implementation details, which is another reason that malloc and new can not be mixed.

=============

 

Another "you should use new/delete over malloc/free. See Scott Meyers' Item 3 "Prefer new and delete to malloc and free" from Effective C++." ... se http://iskren.info/r...+/EC/EI3_FR.HTM

 

 

Some tips about C++ can be found here

http://iskren.info/r...++/EC/INDEX.HTM

 

Finally here is some tips on finding memory leaks

http://www.flipcode....ory_Leaks.shtml

 

However the best tip of all is "Don't leak"

 

EDIT: LATER .... Ooops. I wrote this in wrong thread. Should be in the thread about memory leakage. Sorry

Edited June 8, 2012 by Roland

[Josh]

Seriously? They are iterating through a list of all allocated pointers every time they call delete? This is what a map is for. I know it's for debug-only mode, but come on:

 void RemoveTrack(DWORD addr)
  {
	  AllocList::iterator i;

	  if(!allocList)
		  return;
	  for(i = allocList->begin(); i != allocList->end(); i++)
	  {
		  if((*i)->address == addr)
		  {
			  allocList->remove((*i));
			  break;
		  }
	  }
  };

 

I posted the right way to do this, on Windows at least. It's astonishing to me that all the programmers discussions I found on Google said to use GetProcessMemoryInfo(), which is horrible advice:

http://www.leadwerks...et-memory-usage

[Roland]

Yes. Josh " for debug-only ". Thank's for explaining what a map is used for

You can always make it better by using a map. The idea is the important thing.

 

I posted the right way to do this

Yes... but that does not show where the leak is.

 

Anyway I do not use any of the methods above.

Just wanted to give some links with info on the subject.

 

Personally I use the Output-window from VStudio and DebugBreak, simple as that.

But everyone has their way.

 

I could, but will not go into a debate on this

Hope your leaks go away no matter which method is used.

 

EDIT: LATER .... Ooops. I wrote this in wrong thread. Should be in the thread about memory leakage. Sorry

Edited June 8, 2012 by Roland

[Canardia]

I think one way to test memory leaks, would be to install virtualbox and windows xp on it, and then disable all services. And remove all running processes, including explorer.exe; you can start programs just fine with task manager. I got XP to work fine without any services running, and only 11 processes in task manager. Then you can see much clearer how much memory your app takes.

[Roland]

Its one thing to get information that your program actual leaks.

But the big issues to know where it leaks. This info can be retrieved

by using some debug-commands, the debug output window and DebugBreak.

It does not matter if its C or C++, in a class or in a function. You get the info.

 

EDIT: LATER .... Ooops. I wrote this in wrong thread. Should be in the thread about memory leakage. Sorry

Edited June 8, 2012 by Roland