Circular References Cause Memory Leak?

Question

I'm trying to run down a memory leak in a windows forms application. I'm looking now at a form which contains several embedded forms. What worries me is that the child forms, in their constructor, take a reference to the parent form, and keep it in a private member field. So it seems to me that come garbage-collection time:

Parent has a reference to the child form, via the controls collection (child form is embedded there). Child form is not GC'd.

Child form has a reference to the parent form, via the private member field. Parent form is not GC'd.

Is this an accurate understanding of how the garbage collector will evaluate the situation? Any way to 'prove' it for testing purposes?

Answer 1

Great question!

No, Both forms will be (can be) GC'd because the GC does not directly look for references in other references. It only looks for what are called "Root" references ... This includes reference variables on the stack, (Variable is on the stack, actual object is of course on the heap), references variables in CPU registers, and reference variables that are static fields in classes...

All other reference variables are only accessed (and GC'd) if they are referenced in a property of one of the "root" reference objects found by the above process... (or in an object referenced by a reference in a root object, etc...)

So only if one of the forms is referenced somewhere else in a "root" reference - Then both forms will be safe from the GC.

only way I can think of to "prove" it, (without using memory trace utilities) would be to create couple hundred thousand of these forms, in a loop inside a method, then, while in the method, look at the app's memory footprint, then exit from the method, call the GC, and look at the footprint again.

Answer 2

As others have already said, GC has no problems with circular references. I'd just like to add, that a common place to leak memory in .NET are event handlers. If one of your forms has an attached event handler to another object which is "alive", then there is a reference to your form and the form will not get GC'd.

Answer 3

Garbage collection works by tracking application roots. Application roots are storage locations that contain references to objects on the managed heap (or to null). In .NET, roots are

1. References to global objects
2. References to static objects
3. References to static fields
4. References on the stack to local objects
5. References on the stack to object parameters passed to methods
6. References to objects waiting to be finalized
7. References in CPU registers to objects on the managed heap

The list of active roots is maintained by the CLR. The garbage collector works by looking at the objects on the managed heap and seeing which are still accessible by the application, that is, accessible via an application root. Such an object is considered to be rooted.

Now suppose that you have a parent form that contains references to child forms and these child forms contain references to the parent form. Further, suppose that the application no longer contains a references to the parent for or any of the child forms. Then, for the purposes of the garbage collector, these managed objects are no longer rooted and will be garbage collected the next time a garbage collection occurs.