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.

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

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.

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)

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.

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