Sign in to follow this  
waZim

Memory Leak in Win32 applications

Recommended Posts

Hi All, I have been observing the Win32 Simple Application from http://www.winprog.org/tutorial/simple_window.html NOTE : For some one who wanna help, must go to that link and create a win32 application from this tutorial. And it seems there is a memory leak in the application, which does not makes any sense, since its a simple Win32 Application and nothing is happing complicated inside. when i observe the memory requirements in Task Manager it stays relatively constant, but when i move the window or move my mouse on top of it, resize it or just move it around, restore etc. the memory requirement fluctuates and goes up. any one have any idea of whats going on and can we control that? is there inherited memory leaks in win32 API? Any suggestions, help would be greatly appriciated. .. waZim

Share this post


Link to post
Share on other sites
No. The task manager is not a suitable tool for observing memory consumption in this fashion. It doesn't tell you what you think it tells you. You will need to find a profiling tool or library that can show you more relevant memory statistics (and read the documentation to understand what they mean) in order to make any such judgements.

Share this post


Link to post
Share on other sites
Quote:
Original post by jpetrie
No. The task manager is not a suitable tool for observing memory consumption in this fashion. It doesn't tell you what you think it tells you.


So whats the best way of varifying? and checking for memory consumption and leaks.

Share this post


Link to post
Share on other sites
Typically libraries are used that hook the allocation and deallocation routines in your program. The program is recompiled with those hooks enabled, and the library provides functionality that lets you know what memory is outstanding at a given point in time, which can be used to determine if you leak during application shutdown or during execution at a specific point you determine, et cetera.

In C++, preventative measures are often taken by avoiding manual memory management where possible, preferring idioms like RAII, things like smart pointers and SC++L containers, et cetera.

Share this post


Link to post
Share on other sites
Quote:
Original post by jpetrie
Typically libraries are used that hook the allocation and deallocation routines in your program. The program is recompiled with those hooks enabled, and the library provides functionality that lets you know what memory is outstanding at a given point in time, which can be used to determine if you leak during application shutdown or during execution at a specific point you determine, et cetera.

In C++, preventative measures are often taken by avoiding manual memory management where possible, preferring idioms like RAII, things like smart pointers and SC++L containers, et cetera.


Thanks again,
Yes i have a customed type Memory manager "sort of" which tells me about where i have been doing new calls and not calling deletes on those addresses,

But since i can't see my customed memory manager output for the simple win32 application, for all other taskes my classes inherits from my memory manager and it shows me any "new" and "delete" calls on those object etc.

But on the core API?
And Task Manager kinda scared me, since the Memory requrements were fluctuating.

Share this post


Link to post
Share on other sites
Quote:
Original post by waZim
Quote:
Original post by jpetrie
Typically libraries are used that hook the allocation and deallocation routines in your program. The program is recompiled with those hooks enabled, and the library provides functionality that lets you know what memory is outstanding at a given point in time, which can be used to determine if you leak during application shutdown or during execution at a specific point you determine, et cetera.

In C++, preventative measures are often taken by avoiding manual memory management where possible, preferring idioms like RAII, things like smart pointers and SC++L containers, et cetera.


Thanks again,
Yes i have a customed type Memory manager "sort of" which tells me about where i have been doing new calls and not calling deletes on those addresses,

But since i can't see my customed memory manager output for the simple win32 application, for all other taskes my classes inherits from my memory manager and it shows me any "new" and "delete" calls on those object etc.

But on the core API?
And Task Manager kinda scared me, since the Memory requrements were fluctuating.


There are libraries built into the C runtime for detecting memory leaks automatically for you. If you wrap main with a construct like this:


void main()
{
#ifdef _DEBUG
_CrtMemState initMemoryState;
_CrtMemCheckPoint(&initMemoryState);
#endif

//rest of program goes here as normal

#ifdef _DEBUG
_CrtMemState finalMemoryState;
_CrtMemCheckpoint(&finalMemoryState);

_CrtMemState diffMemoryState;
if(_CrtMemDifference(&diffMemoryState, &initMemoryState, &finalMemoryState))
{
_CrtMemDumpStatistics(&diffMemoryState);
_CrtDumpMemoryLeaks();
DebugBreak();
}
#endif
}



This will then print out a report of any leaked memory (between the check point calls) into Visual Studio's output window. It will also tell you the allocation # of that memory, which if your program is deterministic, you can use _CrtSetBreakAlloc() to break on that allocation number and see exactly what is being leaked.

Share this post


Link to post
Share on other sites
Quote:
Original post by andur
Quote:
Original post by waZim
Quote:
Original post by jpetrie
Typically libraries are used that hook the allocation and deallocation routines in your program. The program is recompiled with those hooks enabled, and the library provides functionality that lets you know what memory is outstanding at a given point in time, which can be used to determine if you leak during application shutdown or during execution at a specific point you determine, et cetera.

In C++, preventative measures are often taken by avoiding manual memory management where possible, preferring idioms like RAII, things like smart pointers and SC++L containers, et cetera.


Thanks again,
Yes i have a customed type Memory manager "sort of" which tells me about where i have been doing new calls and not calling deletes on those addresses,

But since i can't see my customed memory manager output for the simple win32 application, for all other taskes my classes inherits from my memory manager and it shows me any "new" and "delete" calls on those object etc.

But on the core API?
And Task Manager kinda scared me, since the Memory requrements were fluctuating.


There are libraries built into the C runtime for detecting memory leaks automatically for you. If you wrap main with a construct like this:

*** Source Snippet Removed ***

This will then print out a report of any leaked memory (between the check point calls) into Visual Studio's output window. It will also tell you the allocation # of that memory, which if your program is deterministic, you can use _CrtSetBreakAlloc() to break on that allocation number and see exactly what is being leaked.



This seems greate if it really works, i am gonna check it tomorrow. my first try could not compile symbol _CrtMemCheckpoint ..

thanks

Share this post


Link to post
Share on other sites
Quote:
Original post by waZim
Niiiiiiiiice,,

it works..

_CrtMemCheckpoint this was misspelled in your code. :)

..
waZim


Glad it works :) The debugger should really have something like this built into it. This won't catch everything though, I don't think it will catch any static variables that initialize stuff on the heap.

Yeah, sorry about that typo in typing it in here.

You can also call _CrtSetAllocHook and pass it a function that gets called whenever memory is allocated/freed/reallocated. MSDN explains pretty well how it works.

Share this post


Link to post
Share on other sites
Quote:
Original post by andur
Quote:
Original post by waZim
Niiiiiiiiice,,

it works..

_CrtMemCheckpoint this was misspelled in your code. :)

..
waZim


Glad it works :) The debugger should really have something like this built into it. This won't catch everything though, I don't think it will catch any static variables that initialize stuff on the heap.

Yeah, sorry about that typo in typing it in here.

You can also call _CrtSetAllocHook and pass it a function that gets called whenever memory is allocated/freed/reallocated. MSDN explains pretty well how it works.


Thanks for the reply again.

about _CrtSetAllocHook, the following link has a tutorial of how to use all this memory management system from CRT. and explains alot regarding taking the momory snapshots etc..

http://www.codeproject.com/KB/cpp/MLFDef.aspx?fid=185354&df=90&mpp=25&noise=3&sort=Position&view=Quick&select=1121151

What i don't understand and am still searching around is how can i use that information to track the file name and line number out of it where the memory was allocated and was not deleted?

how can i decode this information

Detected memory leaks!
Dumping objects ->
{142} normal block at 0x00367210, 200 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
{141} normal block at 0x00367108, 200 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD

One other thing which i didn't understand is when you say "if you program is Determinstic?" what does that exactly mean?

thanks in advance.

Share this post


Link to post
Share on other sites
Quote:
Original post by andur
Quote:
Original post by waZim
Niiiiiiiiice,,

it works..

_CrtMemCheckpoint this was misspelled in your code. :)

..
waZim


Glad it works :) The debugger should really have something like this built into it. This won't catch everything though, I don't think it will catch any static variables that initialize stuff on the heap.

Yeah, sorry about that typo in typing it in here.

You can also call _CrtSetAllocHook and pass it a function that gets called whenever memory is allocated/freed/reallocated. MSDN explains pretty well how it works.


Actually only this function is enough for what your code is suppose to do.

_CrtDumpMemoryLeaks();

You can dump all the memory leaks with the file name and line number at any point in the application with just this one function call, you don't have to keep record of the memory snaps. and find the difference.

if you want the file name and line number then #define CRTDBG_MAP_ALLOC

refer to the following link.

http://msdn.microsoft.com/en-us/library/e5ewb1h3(VS.71).aspx

:)

isn't this fast ? and easy?

and even better one is the following line of code

_CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );

This one is handy when you don't want to call _CrtDumpMemoryLeaks(); every where your program can exit. enabling this flag will call _CrtDumpMemoryLeaks(); every where your program exits.

..
waZim

Share this post


Link to post
Share on other sites
On other thing which i just found out is that actually this _Crt Rutines are not very advanced way of doing memory management they are only meant for loging your heap allocations, and my current memory management is already quite advanced. in which i have overloaded new and delete operators.

correct me if i am wrong..

..
waZim

EDIT:

Actually if you trace down the _Crt Functions they also end of overloading the new and delete in their way. and calling new with __FILE__ and __LINE__ etc.

Share this post


Link to post
Share on other sites
Quote:
Original post by waZim
On other thing which i just found out is that actually this _Crt Rutines are not very advanced way of doing memory management they are only meant for loging your heap allocations, and my current memory management is already quite advanced. in which i have overloaded new and delete operators.

correct me if i am wrong..

..
waZim

EDIT:

Actually if you trace down the _Crt Functions they also end of overloading the new and delete in their way. and calling new with __FILE__ and __LINE__ etc.


Yeah, the _Crt routines only work on anything that you malloc/realloc/free (and indirectly new/delete, since the default calls malloc anyways). If you are doing some custom memory management, then, no, these won't help you any. They will let you know that you are cleaning up your custom memory manager correctly though.

That simpler method you posted I'll have to take a look at, not that it makes too much of a difference. I stopped looking into this once I found something that worked for me.

The deterministic reference, was that if your program always does the same things in sequence to your commands, then you can use that {142} normal block at 0x00367210, 200 bytes long output to break on the 142nd memory allocation next time your program runs and you'll know exactly what is leaking memory and what calls lead to that point to your program. If there's some random numbers or anything outside of your direct control that leads to memory allocation, then, that's not necessarily going to work as the allocation numbers will be different.

That information is in the format:
{allocation number} address of leak (not too useful), size of leak (handy if you happen to know that one of your classes/structs is 200 bytes).
The data line is just the first few bytes of memory at that location. Its generally not too useful unless it contains a string which is readable (if it say said "foo.bmp" you can probably conclude it is a texture for example)

Share this post


Link to post
Share on other sites
Quote:
Original post by andur
Quote:
Original post by waZim
On other thing which i just found out is that actually this _Crt Rutines are not very advanced way of doing memory management they are only meant for loging your heap allocations, and my current memory management is already quite advanced. in which i have overloaded new and delete operators.

correct me if i am wrong..

..
waZim

EDIT:

Actually if you trace down the _Crt Functions they also end of overloading the new and delete in their way. and calling new with __FILE__ and __LINE__ etc.


Yeah, the _Crt routines only work on anything that you malloc/realloc/free (and indirectly new/delete, since the default calls malloc anyways). If you are doing some custom memory management, then, no, these won't help you any. They will let you know that you are cleaning up your custom memory manager correctly though.

That simpler method you posted I'll have to take a look at, not that it makes too much of a difference. I stopped looking into this once I found something that worked for me.

The deterministic reference, was that if your program always does the same things in sequence to your commands, then you can use that {142} normal block at 0x00367210, 200 bytes long output to break on the 142nd memory allocation next time your program runs and you'll know exactly what is leaking memory and what calls lead to that point to your program. If there's some random numbers or anything outside of your direct control that leads to memory allocation, then, that's not necessarily going to work as the allocation numbers will be different.

That information is in the format:
{allocation number} address of leak (not too useful), size of leak (handy if you happen to know that one of your classes/structs is 200 bytes).
The data line is just the first few bytes of memory at that location. Its generally not too useful unless it contains a string which is readable (if it say said "foo.bmp" you can probably conclude it is a texture for example)


Yea, thanks alot for the time you put in the answers,
I read the stuff yesterday and found ways of using this information, and also putting breakpoints on the Allocation Numbers etc. it was working.

But Again i guess overloading the new and delete and siblings in your own memory manager is a beter way of doing it.


Share this post


Link to post
Share on other sites
Quote:
Original post by waZim
But Again i guess overloading the new and delete and siblings in your own memory manager is a beter way of doing it.
Out of curiosity, why do you have your own memory manager?

Share this post


Link to post
Share on other sites
Quote:
Original post by mutex
Quote:
Original post by waZim
But Again i guess overloading the new and delete and siblings in your own memory manager is a beter way of doing it.
Out of curiosity, why do you have your own memory manager?



By Memory manager i mean, a structure which can log your allocations and de-allocations through out the life of your engine. and at the end dump the results, if there were any memory leaks and such.

Apart from this i would like to enhance this memory manager as such i don't have to do alot of dynamic memory allocations at run time rather maintain pools of the required memory over a span of time. it easily gets tricky and hard to maintain though.

Apart from this i would like to direct my new and such, to do dynamic allocations from stack rather then heaps which are fast and cache friendly.
Now i assume you know about all these things a little. or may be you are an expert.So i would really appriciate if you can give me advice or direct me in a proper way if am talking Nonsense :)


..
waZim

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this