TabControl objects persisting in memory

[Stephen]

Our application is web based.  It basically simulates windows style system of windows within the one browser window.  If we open up a window that uses a tab control, then close it and reopen it, the memory just goes up.  Furthermore, the constructor for the tab is hit one additional time, for each time the window is opened then closed.  Calling the garbage collector didn't resolve the issue.  I tried clearing the Items of the tab control on window close, but that didn't resolve the issue either.  I have tried various other things to try and null out or clear objects, but nothing seems to work.  No matter what I do, all of the tab objects persist.

It is a SL5 application and we are using the latest Telerik Controls.

Also, we have one implementation that uses MVVM and one that doesn't.  They both behave the same way.

[Stephen]

Ok, we have made a little progress in this issue.  We resolved the problem where each tab would cause the constructor to be hit one additional time, each time the window with the tab control is opened, the tab is selected, then the window in closed, then opened again.

This leaves us with the big part of the problem.  Memory does not ever release the view model associated with the tabs.  So, every time you open the window and click on the tabs, the memory goes up.  When the window is closed, the memory doesn't not drop.

Actually, it isn't particular to view models.  I don't want to make it seem like the view model is the cause, because we have a screen that uses a tab control, where each tab has it's own xaml, but it is not done in MVVM.  The same thing happens with either screen.

[Vladislav]

Hello Stephen,

Thank you for this report.
Unfortunately, we aren't able to reproduce the described issue on our side.
Can you please check the attached project which is my attempt to reproduce it. Feel free to modify it in order to closer resemble your scenario/expectations. Also if your scenario differs significantly from my approach, it will be best if you can send us your project (or only the relevant part of it).

I also have some questions regarding your original project:
1. How are you tracking the memory - do you use some memory profiling tool (i.e. JustTrace), check the memory from the "Task Manager" or using some other tool/method?
2. Do you use ChildWindow for the different windows? Or our RadWindow control? Or any other Silverlight's window?

Based on the information provided, there is a possibility that some of your "custom controls" (DawnsPlayground, DougsPlayground, etc..) are actually holding the memory and they may prevent the RadTabControl from garbage collecting itself. Is it possible to check that these controls release the memory properly? 
 
Any additional information that you can provide us with will be highly appreciated.

Kind regards,
Vladislav
the Telerik team

[Stephen]

After doing a lot of investigation, I took the approach of being very thorough in how events are handled and how the objects are handled when the main window holding the tab control is closed.

I went through each of the tabs and made it so that events are subscribed to right before their use, then de-subscribed to them when the web service returned.  This way we didn't have anything potentially holding classes from the GC.  Also, on closing the window, the objects were nulled out and the view models we nulled as well.

Once I did all of this, across all tabs, the GC was able to keep the memory from ballooning.

Also, when I got most of it resolved, I decided to finally give JustTrace a try.  It helped me identify remaining assemblies that were having multiple instances where there shouldn't be.

So, this is resolved.