Esap1,

Actually windows clears the memory fairly well in most cases. Try allocating 5MB of memory, waiting about 10 minutes, and then check the resource meter. I''ve monitored memory using the MFC API which gets you right down to the bytes of swap, and physical memory.

It seems that after your program exits the memory is still "taken". When windows memory management gets around to it, it begins cleaning it up. So the memory gets reclaimed slowly. However for some systems if the memory drops to low, there may not be enough time to clean it up before something bad occurs (like Running MS Word).

Thanks,

CodeMonkey

hm, whaddaya know? I put together a test program that allocated 10 megs, ran it in a batch file loop, and the memory''s never released.

In that case, memory leaks are extra, extra, extra bad. Don''t do them.

Why bother with tools for tracking your leaks?
Just overload the global new and delete operators for your debug version and hold a record of all memory allocations and deallocations then dump any un-freed memory at program termination along with the file and which line the memory was allocated at.

"Paranoia is the belief in a hidden order behind the visible." - Anonymous

"Why bother with tools for tracking your leaks?
Just overload the global new and delete operators for your debug version and hold a record of all memory allocations and deallocations then dump any un-freed memory at program termination along with the file and which line the memory was allocated at."

Hi,

nice idea and i did that a lot of times before in the past. But doing so with most modern compilers means reinventing the wheel because it''s already there, and all you have to do is reading the documentation. Why i recommend to use tools like PURIFY from RATIONAL is that they detect so much more since they instrument all of your code and it''s so easy to find all this little bugs in one run. Why do you think is the complete industry using these tools. Using your idea is may helpfull in some cases, but you will never detect "array bounce writing", leaks and errors in the kernel api functions and also no thread stack overruns etc.


cu

Peter

phemmer,
Of course they are good tools but if you are looking to detect memory leaks and nothing else it's usually not worth the buck you have to cough up for the program. I wouldn't expect them to be free now would I? Besides, reinventing the wheel in this case is almost no work at I'll, all make an example below.

All you need to do is to stick something like this in an header file.

        #if defined(_DEBUG) && CL_DBG_TRACKMEMORYLEAKS#	include <malloc.h>	// These are used internally by our new and delete	void clRemoveAllocRecord(unsigned long addr);	void clAddAllocRecord(unsigned long addr, size_t size, const char* filename, int line);	inline void* __cdecl operator new(size_t size, const char* file, int line)	{		void* p = malloc(size);		clAddAllocRecord((unsigned long)p, size, file, line);		return p;	}	inline void* __cdecl operator new[](size_t size, const char* file, int line)	{		void* p = malloc(size);		clAddAllocRecord((unsigned long)p, size, file, line);		return p;	}	inline void __cdecl operator delete(void* p)	{		clRemoveAllocRecord((unsigned long)p);		free(p);	}	inline void __cdecl operator delete[](void* p)	{		clRemoveAllocRecord((unsigned long)p); free(p);	}#	define DEBUG_NEW new(__FILE__, __LINE__)#else#	define DEBUG_NEW new#endif#define new DEBUG_NEW#if defined(_DEBUG) && CL_DBG_TRACKMEMORYLEAKS	bool clDumpMemoryLeaks(const char* filename);	bool clMemoryLeaksFound();#else#	define clDumpMemoryLeaks(x)	false#	define clMemoryLeaksFound() false#endif        

And then just implement the actual add/remove/dump functions in a cpp file. No biggie. Now, just include the xxx.h file in any file you wan't to track for memory leaks (be sure to include it after any STL headers, I'll give you lotsa crap if you don't - at least with Microsoft's and SGI's STL implementations).

"Paranoia is the belief in a hidden order behind the visible." - Anonymous

Edited by - Staffan on August 11, 2000 8:19:04 AM

Also, just to add to the conversation. The best way to stop a memory leak is to not create one.

What I mean is. I look at a lot of code created and people use dynamic memory allocation when really static would do.

In other words. In your functions, instead of malloc''ing memory try to use arrays as much as possible. This way, when you exit the function the memory is free''d.

As for Purify, only ever used it under UNIX and I personally think its great. Doesn''t spot everything but for what it does it helps.

-----------------------------------------------
All messages are of my own personal opinion and
not meant to offend. But if they do - tough :)

Neuro.