I've been reading a lot about this since I've been asked to fix a C# application that has memory leaking problems, but I haven't found an answer for these 2 issues:
Consider the following code:
private static ArrayList list = new ArrayList();
public void Function()
{
list.add(object1);
list.add(object2);
//didn't call clear() prior to reusing list
list = new ArrayList();
}
Since the list wasn't cleared before creating a new one, will this generate some sort of garbage that won't be released after the static list itself is disposed?
The second issue is regarding Form.Dispose(). I see that a lot of controls available on designer view (i.e. labels, picture boxes) require disposing. It's seems as though calling Dispose() on a Form causes all of these types of controls to be disposed also (correct me if I'm wrong), which is odd since the designer adds an overriden void Dispose(bool disposing) method which does no such thing. I'm assuming that this happens at the void Dispose(bool disposing) method of the base Form class.
The problem with the above is that it is not very clear to me what I need to do to ensure that all of the Form's resources are disposed correctly. I do not understand how the Form knows which objects it needs to dispose. For example, if in my form I have a field which is a custom IDisposable object, will the Form know that it needs disposing? Or should I add the code necessary to release the object myself?
Also, if I do need to add the code to dispose certain objects, then how do I deal with the fact that the designer has already overriden the void Dispose(bool disposing) method? Should I edit the designer generated code or is there a cleaner way to do this?
I hope that this wasn't to confusing, it's a bit hard to explain. Thanks
No, that's not a leak. When the garbage collector goes searching for object references, it won't find a reference to the original ArrayList anymore. You replaced it. So it will automatically destroy that original ArrayList object, as well as all of its elements if they are not referenced anywhere either.
The Form class knows how to dispose itself, as well as all the controls that are child windows on that form. This happens when the user closes the form, the WM_CLOSE message that Windows sends triggers this code. The Form.Controls collection helps it find the reference to all child controls so it can dispose them too.
However, this will not happen if you remove controls from the form yourself. Now it is up to you to call Dispose() on them. Particularly the Controls.Clear() method is dangerous. What is unusual about it is that this causes a permanent leak, the controls you remove are kept alive by the 'parking window'. Which keeps the window handle alive so you can move them elsewhere, on another container window for example. If you don't actually move them, they'll stay hosted on that parking window forever. No other classes in the framework quite behave this way.
This leak is easy to diagnose with Taskmgr.exe, Processes tab. View + Select Columns and tick USER Objects. If this steadily goes up while your program runs then you're leaking controls.
What is the scope of your Static arraylist. Looks to me that it has a form scope. If it is, it will not be disposed since static objects are always considered rooted and has an application life time. In my experience, statics always take more memory and get promoted to gen 2 because of this fact. If you have any doubts, take a .net memory profiler and check it out. You can also take memory dumps and analyze it using windbg to figure out the real cause of the leak.
In many memory-management frameworks, garbage-collected and otherwise, freeing up memory within an application does not generally cause the application to release that memory, but instead record the fact that the memory should be available for future requests. Part of the idea behind garbage collection is that when user code asks for memory and the application knows that it has at least that much immediately available, neither the code nor the application will care about whether any memory not needed for that request is "allocated" or "free". When the last reachable reference to an object is destroyed or becomes unreachable, the object effectively ceases to exist right then and there, but there's generally not much purpose in trying to reclaim memory formerly used by non-existent objects until such reclamation is either required to fulfill an allocation request, or the "memory freed per time spent" ratio is as good as its likely to get.
Note that for the system to reclaim the memory associated with an object, it is absolutely imperative that no reference of any sort exist to that object. If there exist any reachable weak references to an object which is not otherwise reachable, the garbage-collector must invalidate all such references (so they no longer identify the object) before the space used by the object can be reclaimed. If an otherwise-unreachable object has a registered finalizer, the system must put the object on a queue of things needing immediate finalization (thus making it ineligible for reclamation) and unregister the finalizer.
Weak references and the references used for finalization are both invalidated automatically by the GC when all other references to an object are abandoned, and thus do not cause memory leaks. There's another kind of reference, however, which can cause nasty leaks: event subscriptions from publishers that outlive subscribers. If object A subscribes to an event from object B, object A cannot be garbage-collected unless either (1) it unsubscribes from the event, or (2) B itself becomes eligible for garbage-collection. I find myself puzzled at why Microsoft didn't include some means of automatic event unsubscription, but they didn't.
