The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

memory leak detection

I am trying to hunt down a memory leak, but not having much luck. I enabled the memory leak detection stuff in Visual studio (I use VS2005) such as "#define DEBUG_NEW new(_NORMAL_BLOCK ,__FILE__, __LINE__)", but I still get the following:

Dumping objects ->
C:\Program Files\Microsoft Visual Studio 8\VC\include\crtdbg.h(1147) : {2435} normal block at 0x00EAB1F0, 16 bytes long.
 Data: <  `            > F0 F1 60 00 F8 A5 EA 00 A8 B1 EA 00 F8 A3 EA 00

There are a few more lines like this one.
No reference to source code line numbers.

What else can I do to hunt down the leaks??
leaky
Thursday, August 10, 2006
 
 
Raymond Chen talked about the "target rich environment principle" some time back.

http://blogs.msdn.com/oldnewthing/archive/2005/08/15/451752.aspx

Basically, you run your program so it loops around whatever you think is leaking as quickly as possible, and fill allocated memory in such a contrived way that when the leak gets big you'll be able to see what's taking up the majority of the space.

One possible way you can do this is to put a private const char* variable in all your classes with a different a hard coded ASCIZ string, then see what memory patterns get thrown up when your program has leaked a lot.
Ritchie Swann Send private email
Thursday, August 10, 2006
 
 
I have a small clue, but that's not enough right now. My app is using a bunch of COM objects and there is a leak in there somewhere. I am guessing I am not releasing something or whatever, so the leak is not in my code per se. Otherwise, I'd get a line number.

So how do I go about detecting this sorta leak?
leaky
Thursday, August 10, 2006
 
 
Are you using ATL? If so, add _ATL_DEBUG_INTERFACES to your list of defines and compile in debug mode. You'll then get a debug dump of all AddRefs and Releases, which you can view either in Visual Studio's debugger or an external tool like SysInternal's DbgView.

See http://msdn2.microsoft.com/en-us/library/sycfy8ec.aspx for more info.
Ritchie Swann Send private email
Thursday, August 10, 2006
 
 
No ATL, no MFC, no WTL.
leaky
Thursday, August 10, 2006
 
 
Do you have the source for these COM objects you think are leaking?
Ritchie Swann Send private email
Thursday, August 10, 2006
 
 
FWIW, a cursory look at what's being leaked seems to be a pointer to something in your process space, followed by three pointers to areas in a system library such as ole32.dll or kernel32.dll. Does that help?
Ritchie Swann Send private email
Thursday, August 10, 2006
 
 
I don't think so, but maybe I do. :)

I am trying to embed IE into my application. Everything works, except when I quit the application, I get the memory leak message.
leaky
Thursday, August 10, 2006
 
 
> Does that help?

Kinda. I know it has to do with OLE, but it looks like I need to infer the problem from what I am seeing, but I don't think I know enough about OLE to infer what the problem might be...
leaky
Thursday, August 10, 2006
 
 
Are you perchance using the WebBrowser control in shdocvw.dll?

I seem to recall having a similar memory leak issue when embedding IE inside an application. I never got it fixed - I redesigned the software to not use it. Which probably isn't what you want to hear.

Can you just live with the memory leak? I assumed you were writing a server application?
Ritchie Swann Send private email
Thursday, August 10, 2006
 
 
You'll want to try a more industrial strength leak checker, such as this one:  http://www.glowcode.com/summary.htm

They have a demo that you can download and use for a while.

It keeps a stack trace for every allocation that is done, so it can work to trace things when DEBUG_NEW is not working.


But I'm not so sure that the leak would be from an external component - when you enable the memory leak checking, it is reporting on leaks in the CRT heap, which is probably the VC8 specific version of the runtime library (you should check). If it is, then it is not too likely that any of the other compoments were built with VC8, they are going to be using other heaps for their memory allocations. Use depends.exe to see if the other compoments link to the VC8 CRT or not.

It is more likely that the leak is somewhere in your code, from an allocation done in a header file before your #define DEBUG_NEW takes effect. There are many header files that use placement new that aren't compatible with DEBUG_NEW anyway. For these you need a stack trace checker, I definitely recommend that GlowCode one.

The other thing you need to do is keep leak checking always turned on for the debug build, it's much easier to track down leaks when you get a warning when testing your most recent code, you then know that most likely the leak is related to your current changes. If you only check for leaks every once in a while it becomes much more difficult to narrow things down.
Michael G
Thursday, August 10, 2006
 
 
I am attempting to use IMallocSpy since I know it is a COM related leak. I am closer to figuring it out, but it still doesn't make much sense.

Thanks everyone for your help!
leaky
Thursday, August 10, 2006
 
 
> I am attempting to use IMallocSpy since I know
> it is a COM related leak.

Probably the wrong direction - that's the COM task heap, the leak that you've detected is in the CRT heap.

If you've got a leak in the CRT VC8 heap and your code is the only thing using the VC8 heap, then the leak is from some allocation happening in your code.
Michael G
Thursday, August 10, 2006
 
 
OK, it looks like, for some reason, a call to OleCreate() -which embeds IE- causes the leak. I have no idea why though.. Any ideas?
leaky
Thursday, August 10, 2006
 
 
By the way, if you run that code twice, then does it leak twice as much memory? Because if not, then don't bother about it: because it's leaking only some [small] finite amount of memory.
Christopher Wells Send private email
Thursday, August 10, 2006
 
 
I found it. There were a bunch of "new"ed objects not getting "delete"ed within my code, however, I am really suprised that the DEBUG thingie didn't show me the source line for these objects.

I ended up using _CrtSetBreakAlloc() to set breakpoints on the allocation numbers and that's how I figured it out...

Thanks everyone!
leaky
Thursday, August 10, 2006
 
 
> I am really suprised that the DEBUG thingie didn't show
> me the source line for these objects.

Your DEBUG thingie is not set up correctly somehow. Are you possibly missing the second half? You can't just do DEBUG_NEW by itself, you need something like this:

#define DEBUG_NEW new( _NORMAL_BLOCK, __FILE__, __LINE__ )
#define new DEBUG_NEW

Either that, or your #defines are not coming before the code in question.

Anyway, glad you found it.
Michael G
Thursday, August 10, 2006
 
 
Didn't know about _CrtSetBreakAlloc(). Cool. Thanks!
Ritchie Swann Send private email
Friday, August 11, 2006
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz