Bxf and memory issues

Sep 21, 2010 at 8:50 PM
Edited Sep 21, 2010 at 8:50 PM

I am using Bxf and switching back and forth between views the memory footprint increases and I eventually get out of memory errors.  What is the best way to find out what is holding on to these views preventing them from garbage collect?  This is in WPF

Sep 21, 2010 at 11:36 PM

I am experiencing the exact same issue, although I am using Silverlight.  When you start searching for ways to find memory leaks in Silverlight, the results are pretty dismal.  I happened to check on RedGate's site the other day, and it looks like their newest memory profiler now supports Silverlight 4, which is really good news.  I have used their memory profiler in the past (for ASP.NET) and found it really valuable.  I haven't had time to profile my Silverlight/Bxf app, but hope to get to it in the next little while.  They have a 14 day trial, so I would suggest downloading it and trying it out.  If I have a chance to do it, I'll post my findings here.

I'm assuming that the memory leak issue will be the same in both WPF and Silverlight, but I guess we'll find out.  Please let me know if you get a chance to try this out.

Sep 22, 2010 at 3:31 AM

I don't know what's holding onto the views.

If you look at the Bxf code itself, the view factory just creates an instance of the type, it doesn't set up any event handlers or anything. Then it invokes the Bxf IPresenter handler to show the view - which is your code.

But typically your code just sets some dependency property to the view, so the view is bound to the UI. At that point the main page viewmodel has a reference to the view (through its dependency property) and the mainpage UI control (ContentControl or whatever) has a reference to the view.

When you navigate to the next view, both the mainpage viewmodel and UI control stop referencing the old view, because they are now referencing the new view.

Even if your mainpage viewmodel handled an event from the view, it wouldn't matter, because that'd set up a reference from the view to your mainpage viewmodel. The only way an event can be holding the view in memory is if the view is somehow subscribing to an event from some static entity - like your mainpage viewmodel, mainpage xaml, mainpage model (if any) or the bxf.shell.instance - those are the 3-4 objects that are basically static.

But normally your view has no code behind, and so I can't see where it would end up handling events from any of those 3-4 objects.

Sep 22, 2010 at 8:06 PM

Ok, I put the ANTS memory profiler on my app, and this is what I found:

Rocky is correct, it isn't Bxf that holds on to the views.  It looks like the viewmodel is being held by a Csla.DataPortal<T> FetchCompleted event handler.  Further up the chain, it is being held by a Csla.WcfPortal.WcfPortalClient FetchCompleted event handler.  I'm not sure where to proceed from here, because I didn't write any of those event handlers.  It looks like ViewModelBase<T> creates the Csla.DataPortal<T> FetchCompleted event handler.  Perhaps it needs to unhook it once it's complete?

Any help would be greatly appreciated.

Sep 24, 2010 at 12:29 AM

That's very interesting indeed.

I'm curious, was this with CSLA 3.8.x or CSLA 4.0.x?
We have 4 largish Csla+Silverlight projects about to go into production, so I finding a solution to this issue would be very valuable to us.

Perhaps this issue should go back to the CSLA forum (haha.. that's where it started).

Sep 24, 2010 at 3:27 PM
Edited Sep 24, 2010 at 3:42 PM


That is where I started it. 

I installed the ANTS memory profiler as well and found at least one of my issues is I'm using the Telerik Ribbon control and after a few messages on their boards, they have confirmed that their ribbon has some memory leaks and they are working on it.

Sep 24, 2010 at 4:57 PM

This is the problem with memory leaks.

More than one Magenic client has run into memory leaks with specific controls from different third party vendors. I hadn't heard about an issue with the Telerik Ribbon control - that's a new one for me.

Of course it is also possible to build CSLA object graphs that create memory leaks by doing things like holding object references in static fields (directly or indirectly) or handling static events - things like that.

And I am sure there are ways to mis-use the Bxf.Shell instance to create memory leaks, though I hope that's relatively difficult as long as there's only one handler for the IPresenter events over the lifetime of the application. Bxf doesn't use any other events, or hold any static references, so it should be relatively difficult to trick it into causing a memory leak.