Thread: Unmanaged Heap Memory Leak

LeakDiag

Also, if this has anything to do with the DirectShow.net library, are you using the debug version of the assembly?

I didn't ask because of that. But I can see that you had the debug version of the assembly. So that's fine.

You can be almost sure the leak is on this library if you aren't doing any other kind of access to unmanaged code. But it can still be provoked by your own code if you are accessing these resources the wrong way (you mentioned before lack of proper documentation for this library and that may be a problem here).

What I suggest you do for now to at least point at the source of the leak, is to make selective commenting of your source code that accesses unmanaged code (directly or indirectly through directshow.net) while checking perfmon until you get a flat line for unmanaged memory usage. Here's how:

1. Run you app and start perfmon
2. Add two new counters to perfom
2.1. From the section ".Net CLR Memory", select "#bytes in all Heaps" and associate it with your process
2.2. From the section "Process", select "#private bytes" and associate it with your process

Start commenting any relevant sections of your code and rerun it. You want a flat line for "#private bytes". Once you get that, you located the source of the leak. Or at least the managed code that controls the source of the leak.

EDIT: You may have to scale the "#private bytes" line a bit. If it's set at the top of the graph, doubleclick that marker in the listbox at the bottom of perfmon, and under the "Data" tab decrease the scale by moving up on the dropdown box that you get from the "Scale" button. This will allow you to set that line closer to your managed heap line and in full view.

Now, once you locate the leak, you are not off the hook. Post the code here if you can't see anything wrong with your managed code. If we can't either, chances are the leak is located within DirectShow.Net. But at least you'll know the resource you are using from it that is causing the leak.

Leaks in the unmanaged heap are simple to fix and find through standard C++ leak checks and leak detection methods. Leaks in the managed heap is where the fun begins and some of those are very hard to track down and/or actually determine if they are a leak or just a result of a very lazy GC. Most of the tools mentioned in this thread are for finding managed heap leaks.

The only way you can really leak DirectShow objects is improper COM object cleanup and detecting COM leaks is a completely different process than detecting managed/unmanaged heap leaks. If you call CoCreateInstance or CoCreateInstanceEx you also must then call Release on the interface pointers you get back from those method calls. If you do not do this you will leak DirectShow. COM leaks also compound themselves b/c normally COM is like having a toolbox full of drawers and tools in them. One drawer may contain several tools and/or other drawers. If you leak the parent object then you will also leak all of the objects it manages or that spawned via its various interface calls. Direct3D also has this same type of structure. If you leak a texture or two or a vertex buffer then the entire device will most likely leak which will cause hundreds of leaks b/c the device could not clean up or was in a bad state to do so. Also keep in mind that some COM methods increase the ref count on the object and if you do not call release on it then your final release will leave the ref count at 1 and the object will not clean up.

There are COM based tools to detect these leaks. Direct3D leaks can be found via the dxcpl and by checking break on memory leaks and entering the allocation number you get back in from Direct3D into the edit box. This information will only be returned if you define D3D_DEBUG_INFO. I'm sure there is a similar approach to DirectShow and since DirectShow used to be a part of DirectX you may still be able to use the DirectX control panel method for detecting leaks but I cannot verify that since I do not work that heavily with DirectShow.

I'm confused at a part of that code, but that may be because of my only partial knowledge in mixing managed and unmanaged memory. Not something that I had to so far, except once. But here it goes, anyways:

Why not?

Code:

GCHandle imgch = GCHandle.Alloc(imgBuffer);

// create the new bitmap
Bitmap bMap = new Bitmap(cam.Width, cam.Height, cam.Stride, System.Drawing.Imaging.PixelFormat.Format24bppRgb, GCHandle.ToIntPtr(imgch));

// free the handle
imgch.Free();

Anyways, I don't think the above -- if valid -- will have any effect. It's actually more of a question than a suggestion. Here's however a couple of thoughts:

- How does the Click() method initialize the intPtr? Check if it is with AllocCoTaskMem.
- If the above is true and this code represents the only two situations where allocation e deallocation of unmanaged memory are present, then the leak is not on that piece of code -- or is, but at the library level.

Check Virtual Ace's post for hints on finding tools to debug COM. You may wish to also email the library author. If that's all your code is doing, they will want to know there's a possible leak in Click() -- being that my personal bet.

EDIT: Oh and one final note: Only use implicitly typed variables on those instances where they are needed (or convenient). It's poor form to use them this liberally. I understand you probably just copy-pasted and made the necessary changes, but there's no excuse to use them as it is shown in your code.

Originally Posted by Elkvis

Honestly, criticizing me for a piece of code (that is completely valid code) that uses two instances of the "var" keyword contributes nothing to a solution to my problem. I appreciate the help you've offered so far, but please try to keep to the subject at hand instead of trying to "teach" me how to write better code.

Yes. Well, good luck.