Memory leak-Undisposed instances?

Use this forum for questions on how to use .NET Memory Profiler and how to analyse memory usage.
Post Reply
Chris Bardon
Posts: 2
Joined: Wed Nov 09, 2005 6:35 pm

Memory leak-Undisposed instances?

Post by Chris Bardon » Wed Nov 09, 2005 6:44 pm

I have a .net application that appears to be leaking memory, although using the profiler I haven't been able to find anything on the managed heap that is being referenced outside of a garbage collection. I did notice that the win32 heap seemed to be growing though, and checked the dispose tracker to find that there are a whole pile of undisposed instances. My app uses a lot of webRequest/response methods, but I'm pretty sure that they're all closed correctly. I tried a test application that just did this:

while(true)
{
System.Net.WebRequest req=System.Net.WebRequest.Create(@"http://chris/TestWebService/TestService.asmx?WSDL");
System.Net.HttpWebResponse resp=(System.Net.HttpWebResponse)req.GetResponse();
resp.Close();
}

I ran this inside the profiler, and could see the memory going nuts (but staying basically flat), but the undisposed instances tracker climbing. It turns out that each time the response is called, there's an undisposed System.Net.HttpWebResponse, System.Net.ConnectStream, and System.Threading.ManualResetEvent left, which I think is causing my leak. Any idea why this isn't being cleaned up? Am I reading the profiler results correctly?

Thanks for the application though-if this turns out to be the problem, it's certainly made my life easier!

Chris

Andreas Suurkuusk
Posts: 1029
Joined: Wed Mar 02, 2005 7:53 pm

Post by Andreas Suurkuusk » Thu Nov 10, 2005 8:41 pm

The undisposed instances of System.Net.HttpWebResponse and System.Net.ConnectStream are actually "falsely" identified as undisposed. The problem is that the Close method are used to "dispose" the instances, and the Close method does not call the Dispose method. It's the other way around, the Dispose method calls the Close method. The ManualResetEvent instances, on the other hand, seem to really be undisposed. This causes the unmanaged event resources to be used for too long, and the managed memory usage will be higher, since the instances get promoted to a higher generation since the must be finalized.

Unfortunately, I don't think that the undisposed ManualResetEvent instances are causing you the memory leak.
Best regards,

Andreas Suurkuusk
SciTech Software AB

Chris Bardon
Posts: 2
Joined: Wed Nov 09, 2005 6:35 pm

Post by Chris Bardon » Thu Nov 10, 2005 9:43 pm

Then if those aren't causing the problem, then I have no idea what's going on. There are no lingering references identified, and comparing the snapshots of the heap tells me that the managed heap is the same size, and that only the unmanaged heap is growing. Since my app is all managed code, it must be a managed object that uses an unmanaged resource. Looking at the dispose tracker, the only objects that are showing undisposed instances are the ones I mentioned. Is there something else that I should be looking at? Is there another tool I can try to find out which objects are holding the unmanaged memory? I know from your other posts that you're working on adding an unmanaged tracker to the tool, which sounds like a great help, but that doesn't help me in the immediate term when I need to fix this problem. :) (unless, of course, there's a preview version available).

Andreas Suurkuusk
Posts: 1029
Joined: Wed Mar 02, 2005 7:53 pm

Post by Andreas Suurkuusk » Thu Nov 10, 2005 9:56 pm

I'm sorry, but I don't have any suggestions on how to identify your unmanaged memory leak. Except of course that the coming unmanaged resources tracker will help you. We will provide a preview of the resource tracker for registered users as soon as we have a working version. I expect that it will be available within a month or two.
Best regards,

Andreas Suurkuusk
SciTech Software AB

Post Reply

Who is online

Users browsing this forum: No registered users and 14 guests