Memory leak

 Hello,

 We're using your PropertyGrid in our app and have discovered that objects connected to it often aren't garbage collected when we'd expect them to be. Given that our app generally uses quite a lot of memory and has strict performance requirements, this leak has become a serious problem.

I've prepared a sample VS project that reproduces the issue (attached). In the zipfile you'll also find a renention diagram created by a memory profiler for one of the WindowBMP objects that weren't collected. It is referenced by a PropertyNode.

Please have a look and let us know if there are any workarounds or fixes for this issue. Any help will be greatly appreciated.

Cheers,

Lukasz

Hello Lukasz,

This appears to be a garbage collection issue.  If I call GC.Collect and GC.WaitForPendingFinalizers, the retained objects are collected and the memory usage drops back to near normal.  (Calling these methods repeatedly reclaims even more memory.)  In your repro case, modify the DisconnectButton_Click as follows:

private void DisconnectButton_Click(object sender, RoutedEventArgs e)
{
    MSPropertyGrid.SelectedObject = null;
    GC.Collect();
    GC.WaitForPendingFinalizers();
}

Click the Connect button many times and you will see memory usage go up, as you do at the moment.  Now click Disconnect and you will see it drop back considerably. Click Disconnect a couple more times and you will see it drop back a little more.

Please note that there were some memory leaks in the RTM version of the property grid which have since been fixed.  So if you are using the RTM version, you will need to update your copy to get the above to work.  You can get the latest build from the store (retail version) or from here (trial version).

Please let us know if you still see problems after upgrading to the latest build and implementing the GC.Collect / GC.WaitForPendingFinalizers fix.

 Hi Ivan,

 Thanks for looking into this and a fast reply. Forgot to mention, I've been using the nightly build for my tests (25/09).

Forcing garbace collection does release most of the memory, however some objects still remain, which seems to have something to do with expanding the property tree (memory profiler shows that objects are retained because of a reference from a PropertyNode).

Using the test app (with your additions), I can connect objects multiple times and as long as i don't expand the property tree, they are all reclaimed on clicking Disconnect. However, if I do expand the root of the tree and hit Disconnect, the connected object is not reclaimed. Interestingly, running the application once, I can get at most two objects to leak out (second one by expanding further property nodes). After that all connected objects are always collected on disconnect.

However in the context of our application, this is still a problem, since some of the objects connected to PropertyGrid can be quite large, so leaking out even a few instances can decrease performance. Please let me know if there's any more information I can provide to help you investigate this.

Cheers

Hi Lukasz,

I'm not having much luck cracking those last couple of retained objects, so I've instead implemented a workaround that, from my testing, addresses your problem "well enough."  Your feedback is welcome.

I've added a property to the grid called NodeClearanceMode.  If you set this to Aggressive, the grid will actively disconnect references from its internal data structures to your business objects -- in your demo example, the very large BitmapSource object.  This means that although some internal structures may be undesirably retained (i.e. there is still a leak), they will not cause the large business objects to be retained (i.e. it is the 112-byte Node objects which get leaked, not the 100 MB bitmaps).  The large business objects become eligible for GC even though the Nodes have been retained.

With this option in effect, after connecting and expanding half a dozen objects in your demo app, then running the GC a couple of times, I see no noticeable leak.

The down side of aggressive clearance is that it makes Nodes unusable after they have been removed from the grid.  This can be surprising and can cause compatibility issues.  For example, the SelectedGridItemChanged event provides access to the previous and new selections.  If you were to change the SelectedObject, then select a new grid item, the previous selection would refer to a Node that was now cleared.  In the Default NodeClearanceMode, where we wait for the GC to reclaim things, this isn't an issue -- you can safely use a Node as long as you have a reference to it.

This feature will be in nightly builds dated 30 Sept 2009 and above, available after about 1430 GMT from the downloads page (trial edition) or the store (retail editions).

I appreciate this isn't an ideal solution but I believe it will address the leaking of large objects -- please let us know if you still see the problem or if you are doing other things in your app which turn out to be incompatible with the aggressive mode.