Question

I’m writing an application where after a user uses it – he can ‘reset’ it and use it again. The actual use creates some objects including Controls.

I checked the memory usage using Process Explorer and discovered that when the app is used – there’s a rise in memory-use, but when the app is ‘reset’ – the memory-use hardly goes down.

So at the ‘reset’ I Dispose of all of the Controls recursively, and even added a GC.Collect(); to boot. But Process Explorer -> (app's-) Properties -> .Net CLR Memory still shows lots of stuff on the heaps and lots of memory used.

Is this (necessarily) a memory leak? And how come the forced GC doesn’t help?

EDIT:

I added the GC.Collect(); just for debugging – for determining if there is a leak. I’m not worried about a ‘temporary leak’ until the GC works, I’m just trying to find if there are objects that never go out of scope (though I haven’t found them yet) or if it’s just a matter of time, and the memory will be reclaimed.

Answer 1

Is this (necessarily) a memory leak?

Well… yes and no. It’s for the most part impossible to have a true memory leak in a C# app, and even the types which utilize native resources under the hood will clean up after themselves in their finalizer if Dispose() was never called.

Regardless though, it is possible to have stale references and native resources which take too long to clean up (or poorly written native functions which leak themselves), which has the same practical result as a true memory leak would in an unmanaged language.

And how come the forced GC doesn’t help?

You gave the GC a suggestion and it chose not to take it. GC.Collect() doesn’t force the GC to clean up everything and the documentation tells you as much. Secondly, is this memory usage actually causing a problem? How much memory is being consumed? Does it ever get freed? If it is just a small amount then you’re probably worrying about nothing, let the GC do its job.

Without seeing your code all I can do is to guess. There are a couple of ways in which memory pressure can build up in a C# app.

1. Stale references. Lists of references to "dead" objects that you never clear. Event handlers can cause this as well. For example, a static event should always be unsubscribed to because the event delegate holds a reference to the subscriber.

   So, if the subscriber goes out of scope without unsubscribing to the event you essentially have a memory leak because there is always a valid reference to these "dead" objects. Note that the typical use case for events does not cause this to occur because the parent (event publisher) typically goes out of scope when you need it to.

2. Not disposing of objects which implement IDisposable. Sure, they probably clean up after themselves in their finalizer (all .NET IDisposable types do and the rest should), but finalizers run at indeterminate times, making the whole thing unpredictable. Make sure to call Dispose() (use a using statement when possible) asap.

3. Large object heap fragmentation. If you are allocating a lot of "large" objects (objects that are > 85,000 bytes) then it is possible for this segment of memory to become fragmented. This memory is not cleaned up as often as 0th and 1st gen objects allocated on the standard heap are.

The .NET GC is complicated and usually very good at its job. Sometimes it is acceptable to call GC.Collect, but you should understand when it is a good idea and also realize that it may or may not do what you want it to. For example, if you create a large amount of short lived objects.

I have had good experiences using RedGate’s .NET memory profiler when I had exhausted other avenues. I don’t work for them nor am I affiliated with them in any way just so you know, and they also have a free trial. Worth a look.