views:

166

answers:

4

For debugging purposes, when I'm writing an app, the first thing I do is put the following into the stdafx.h:

// -- leak detection ----------------------------------------------------------
#ifdef _DEBUG   
// http://msdn.microsoft.com/en-us/library/e5ewb1h3(v=VS.80).aspx
#define _CRTDBG_MAP_ALLOC   
#include <stdlib.h>
#include <crtdbg.h>
#define DEBUG_NEW new(_NORMAL_BLOCK, __FILE__, __LINE__)
#define new DEBUG_NEW
#endif

Then I add the following to the beginning of the program's main() function:

#ifdef _DEBUG
_CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );
//_CrtSetBreakAlloc( 670 );
#endif  

Redefining the new operator to give leak information is a useful tool. But what about CoTaskMemAlloc and CoTaskMemFree ? How can I detect leaks using these?

I'm writing software that uses COM and DirectShow and need to know how to trace leaks caused by using CoTask allocations.

thanks!

+6  A: 

Get rid of manual memory management and you'll get rid of leaks. Embrace RAII, and never use a resource unless it's wrapped in a handler whose single purpose is to wrap that resource.

I don't think I had a memory leak (or a crash, FTM) in years. But then I have written delete less than half a dozen times in the last decade.

sbi
that's hardly a helpful comment
freefallr
@freefallr How is it "hardly helpful"? Unless you have very specific needs which prevent you from using RAII (which you never mentioned, so one assumes you're unaware of the technique), this does help you prevent memory leaks, which presumably is the point of detecting them? Sure it doesn't answer your question directly, but it does provide a generally better way of going about doing things, doesn't it?
blwy10
@freefallr: So pointing out a way to prevent you from breaking your bones wouldn't be a good answer to a question about how to recover from repeated bone fractures?
sbi
@sbi: The difference would be that you can unbreak your bones by avoiding re-breaking them. Refactoring your code to use RAII will fix your memory leak issues and is undoubtedly absolutely worth it.
DeadMG
You certainly seem more experienced than me. But folks who seem more determined to argue and back up their initial, vague statements are unhelpful, and only steer the thread of conversation into inevitable argument. How is that helpful?!!My program receives media frames from a network source. These media frames must be passed along to DirectShow filter supplied by a 3rd party (MainConcept), so (i) the filter is a black box and (ii) I believe that the filter isn't deallocating media frames like it should be and (iii) directshow filters must receive media frames allocated via CoTaskMemAlloc
freefallr
In general I agree sbi here. Adopt RAII. With that said you still can get memory and resource leaks (for various reasons). Then you can get a tool like Deleaker: http://www.deleaker.com/index.html.But most often what I usually do is that I hook into the functions in question using the detours library: http://research.microsoft.com/en-us/projects/detours/and track the resources myself.
FuleSnabel
@FuleSnabel: Detours is undoubtedly worth its weight in gold!
dirkgently
@DeadMG: Even coming back to read your comment again more than a week later, I still don't have any idea what your were saying - and whether you were agreeing or disagreeing with me.
sbi
@sbi: That's because I got you confused with the other guy. I agree with you but disagreeing with you because I misread the post, as it were.
DeadMG
@DeadMG: Ah, now it makes sense even to me. Sorry for being so dense...
sbi
@sbi: That's ok, I didn't exactly get it right first time either.
DeadMG
+1  A: 

There is also application verifier. It can track a whole bunch of other issues as well apart from leaks like places where you forget to free win32 objects such as handles etc ...

The MSDN link is: http://msdn.microsoft.com/en-us/library/ms220948(VS.80).aspx

Taken from a similar quesiton at http://stackoverflow.com/questions/2820223/visual-c-memory-leak-detection/

obelix
+1  A: 

But what about CoTaskMemAlloc and CoTaskMemFree ? How can I detect leaks using these?

You cannot for the same reason that malloc/free doesn't help you to detect leaks. You need to wrap them suitably to help you with leak detection.

As other posters have said if you are worried about leaks, then start designing your application ground up with this requirement in mind. Use custom allocators where you can manage/track allocations/deallocations.

Did you happen to visit this question: Usage of CoTaskMemAlloc?

dirkgently
I didn't mean that I wanted to detect leaks using these calls, sorry if my statement was unclear. I only meant that I wanted to detect possible leaks of memory that had been allocated using the CoTask calls.
freefallr
My program receives media frames from a network source. These media frames must be passed along to DirectShow filter supplied by a 3rd party (MainConcept).So, (i) the filter is a black box and (ii) I believe that the filter isn't deallocating media frames like it should be and (iii) Directshow filters must receive media frames allocated via the "COM-aware" CoTaskMemAlloc.Essentially, while I can allocate the frames, it's up to a 3rd party component to deallocate. I want to be able to prove that the 3rd party component isn't deallocating properly.
freefallr
This is bad design. A thumb rule of good design is he who allocates, frees the resource.Since the deallocation is in a different library your life isn't exactly a bed of roses. I would try to prove that the 3rd party library actually deallocates all frames, fire up WinDbg, put a breakpoint at `CoTaskMemFree` and wait to see if ever the break point is hit while I am inside the third party.
dirkgently
+1  A: 

Visual Leak Detector - pretty easy to use and there'e no overhead for the app built in release.

celavek