I'm aware this is a Silverlight bug but right now there are work-arounds that work if the controls we're using aren't defined with inline templates. Is Telerik aware of this issue? I'm sure you are..but does the work-around work for RadControls? Should we invest our time changing our xaml to address an issue that, we're not sure that is going to be resolved with the workaround, and it is most likely to be solved in few months?
I'd like some clarification on this, because right now it's hard to make a decision if we're buying RadControls or not.
Thanks in advance,
MF.
38 Answers, 1 is accepted
We are aware of this and other issues in the platform. We have talked with the MS people responsible for those to be fixed and they assured us that a fix in the platform will be pushed very soon and will address these issues, so think of them as something temporarily.
The workarounds are not very good - that is why we decided that it will be better if we just wait at the moment. If you have any other questions - please let us know.
Greetings,
Valentin.Stoychev
the Telerik team
Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items.
We are facing same problem, and its growing :(
last post was on (https://betaforums.silverlight.net/forums/p/171739/430211.aspx) was 10 days ago.
Do you have some new info when will Microsoft fix this?
If this fix is not going out soon we are going to fallback to SL3
(which is big lost of time, since we have upgraded same app from SL3)
Tnx
We don't know when this fix will be released. According to the latest comments the issue has been resolved and is in test:
https://betaforums.silverlight.net/forums/p/171739/430211.aspx
Best wishes,
Valentin.Stoychev
the Telerik team
\joe
According to Tim Heuer from Microsoft "you don't necessarily need to compile your apps using the new bits" and "This was not a developer-related fix, but more of a runtime fix".
So we don't need to wait for new Telerik controls build to check if leaks are gone (one can build for own usage though).
And we already know that memory leaks are still there! Even recompiling from sources doesn't help.
I wonder what Telerik has to say now for all people experiencing huge memory leaks from their controls...
Regards,
Jakub
If these leaks in the framework are fixed you will not have memory leaks with our controls. Unfortunately fixing memory leaks in the core platform is bit our of our control.
Greetings,Vlad
the Telerik team
I don't quite understand you. What 'framework' and what 'core' do you have in mind? How it relates to SL runtime and Telerik controls? What has Microsoft fixed according to you? And what simple developers like me have to do more to not experience more memory leaks related to DataTemplates that kill any serious application after few minutes of usage?
btw. why this example which is yours still leaks?
http://www.telerik.com/ClientsFiles/212594_windowmemoryleak.zip
Regards,
Jakub
How Silverlight is related to Telerik Silverlight controls? Telerik Silverlight controls are built on the top of Silverlight and will use stuff like from the Silverlight like DataTemplates. If they leak in general every control no matter Telerik or other will leak as well.
Sincerely yours,Vlad
the Telerik team
Your answer is still unclear and doesn't bring us any closer to a solution. Do you suggest that MS has fixed only some of bugs in Silverlight and some are still left there? Reading all the forums I though you work close enough with MS as early adopter (and you had enough time) to fix all the problems... You can't even imagine in how big trouble I am trying to develop and sell something that is unusable. I've been patient for few months (you told me 'just wait') and what I got is big disappointment.
Kind regards,
Jakub
Indeed we work closely however we can only report leaks. Every leak related to Telerik controls directly is/will be fixed immediately - as I said we cannot fix general Silverlight leaks like these.
Sincerely yours,Vlad
the Telerik team
http://support.microsoft.com/kb/2164913
According to them (Issue 7) they've resolved 'inline data template' problem. I use this fix, I use your recompiled controls (0812) and I use memory profiler. Memory leaks are still there. Who is responsible for that: MS, Telerik, me? Please answer. Thank you.
Regards,
Jakub
Please check the last posts in the same thread. It seems that DataTemplate problems are not yet resolved.
Greetings,Vlad
the Telerik team
According some random users the problems are not resolved.There has been no response from Microsoft to that effect. It would be very helpful if you could be a little bit professional about this.
According to Tim Heur from MS:
" We work closely with our control vendors on every release. They are a part of our early adopter programs and have access to these verification builds.
I assume 'control vendors' means you (at least I hope that's you, otherwise I bought the wrong controls...)
As your end users we have absolutely no access to any information from MS regarding these issues. We don't get the early adopter builds, and there is no way for us to feed back issues directly to Microsoft, other than through ad-hoc forum posts that the odd MS employee with some sort of commitment to their product may occasionally frequent.
Which makes me think, if MS works closely with control vendors, and you are one of those control vendors ... why are you getting your information from the same half-baked forum post I am ?
We rely on you to liaise with MS, identify if an issue is your issue or their issue,and either fix it or request that MS fixes it and keep us in the loop.
I have been waiting for this fix for a month and a half, with live users using a virtually unusable app (and taking ALOT of heat). I would have thought that in that time you guys would have been testing the early adopter releases, verifying bug fixes and feeding the info back to MS.
Please don't tell me you have been sitting on your hands and assuming everything will work out just fine when MS releases their fix...
I don't like to be apologetic but we've done what we can - we have given Microsoft feedback about the early bits we received. We gave them repro's of the problems we have encountered. We immediately notified them about key things that the latest release does not fix. It's not as if we were standing still or that we don't care.
Unfortunately, for some of the memory leaks there are no viable workarounds. Even though some issues are inherent in the Silverlight 4 runtime, we have ways to fix them and we are hard at work. But for some others... we can't do more than arm ourselves with patience and wait. I would like to once again stress that all of the issues we are talking about in this thread CAN be reproduced with the Microsoft's DataGrid so it is not related to our product only and we do not want to use Microsoft as an excuse for our failure to fix our own problems.
While I wish the MS team could immediately solve the issues all of us encounter, they are an organization like all of us. They work with limited resources they have deadlines, they have priorities, etc. So no point blaming them for anything - they know what are their priorities and what they are doing about it. I guess the only thing all of us can do is to vote on MS Connect for the issues that plague us the most.
Best,
Stefan Dobrev
Team Leader WPF/Silverlight Teams
1. What specific issues HAVE been fixed by the fix, from what you tested.
2. What specific issues HAVE NOT been fixed by the fix, from what you tested.
3. What are possible workarounds for the problems, if any.
4. What controls are affected by the leaks and in which situations.
Just to be clear, I'd appreciate some very explicit/clear answers to the points above, especially related to the Telerik SL controls. So please no "memory leaks with inline templates have been fixed" answers :)
This is so that we can at least resolve/workaround SOME of the problems and know which others we just have to wait for.
I mean, as one of the previous posters said, if you are in contact with MS and know exactly what's going on, why not shed at least some light for the rest of us (because MS for some reason doesn't really do that). That way maybe we can come up with a believable story for our customers and not lose our business, which means, of course, also your business.
Thanks in advance,
Adrian
We are in need of the same answers that Adrian asks for. We are approaching a deadline here and we also want to buy RadControls but these memory leaks are becoming a serious problem that needs to be addressed.
Thanks,
Manuel FelĂcio.
We are also contemplating buying Telerik controls, but soon we have to look for alternatives.
Here are the explicit answers you are waiting for:
- What specific issues HAVE been fixed by the fix, from what you tested?
- We have tested scenarios when you have a custom control in the ControlTemplate of another custom control. A lot of our controls were leaking especially the numerous rad buttons we are using all over the place. Fortunately this issues was resolved in the GDR release.
- We have also tested leaking of RepeatButton, which was fixed as well.
- What specific issues HAVE NOT been fixed by the fix, from what you tested?
- Inline DataTemplate, instantiated via DataTemplate.LoadContent() method.
- Impact: All controls, which are using the above method to load templates. The primer example here is RadGridView.
- Workaround: The "official workaround" from Microsoft is to use a StaticResource instead.
- Note: Microsoft's SDK/Toolkit controls are also leaking - DataGrid, DataForm to name a few.
- TemplateBinding to a custom dependency property in a Popup's Content
- Impact: RadComboBox, menus, almost all of our pickers.
- Workaround: There is currently no workaround from Microsoft. We are investigating a numerous ways to implement a workaround in our code base. Those include implementing our own custom popup, using custom attached bindings, etc. We are currently testing all those possible solutions and evaluating their impact: code changes, XAML changes and so on.
- Note: Microsoft's controls do not expose this behavior, because their functionality is pretty basic.
- Inline DataTemplate, instantiated via DataTemplate.LoadContent() method.
We are also considering pushing a new official service pack release which will have all known memory leak fixes packed-in as well as contains fixes for reported browser zoom problems. Regarding the time frame for this servicing release it may happen in a two weeks time - giving us time to validate all the possible approaches for implementation. Rushing to the first working solution and not evaluating others is something that we will not do. As you know the only way to go fast is to go right.
Again your opinion is the one that counts so please share it with us.
Sincerely yours,
Stefan Dobrev
Team Leader WPF/Silverlight Teams
From our own testing (updated today) we have found the following controls in our project to leak: DropDownButton, ComboBox and Menu. The TreeView was fortunately fixed when we used resource based templates - other controls in the clear: ToolBar, TabControl, normal buttons, Window and BusyIndicator.
I wanted to jump in the discussion and make an official statement - this issue with memory leaks is a top priority for our XAML product teams, and for the company for that matter. We decided to put on hold pretty much any new development in Silverlight and WPF until we fix the outstanding issues. We understand the severity of the problem and hope to be able to ship fixes in the coming weeks. As you can imagine, it is not an easy task as many of the issues are related to base plugin technology but we have ideas how things may work out. I don't want to scare you, but there may be breaking changes in the XAML and the API. It is not 100% certain but it is quite possible. We cannot wait for Microsoft to roll out a patch and we will need to do things on our own, whatever it takes. While it might be a small inconvenience to change a few things here and there if you have custom control templates, I think the benefit of having working apps is much bigger and is worth the changes and the extra effort on our end.
Btw, we are using SL extensively in our own internal systems and in applications such as TeamPulse and Sitefinity and we feel your pains.
We will be posting more details on this thread as we move on with the resolutions of the problems. Meanwhile, please continue sharing your observations and test cases.
Vassil Terziev
Co-founder/CEO
Telerik
We will be looking forward to test your internal builds and give as much feedback as we can.
RadGrid seems to be fixed/better - I haven't tested CRUD operations or loading huge amounts of data. But loading it, filling it with some data and closing it releases memory.
RadDropDown & RadComboBox is NOT fixed (the release notes might give the impression that they are according to what Telerik wrote in this thread) These two are used in almost all our user controls and are preventing GC.
Thanks for taking the time and trying out our latest internal build that contains our fixes for Silverlight's memory leaks. We have done extensive testing on our side using this build and our test scenarios are not leaking. Can you share more details about your case? Sending us a small sample repro application will help us identify the root cause for this.
Regards,
Stefan Dobrev
Team Leader WPF/Silverlight Teams
<
Grid
x:Name
=
"Grid1"
Margin
=
"1"
>
<
telerik:RadToolBar
x:Name
=
"RadToolBar1"
>
<
Some
buttons .../>
<
telerik:RadToolBarSeparator
/>
<
telerik:RadDropDownButton
x:Name
=
"RadDropDownButton1"
/>
<
telerik:RadToolBarSeparator
/>
</
telerik:RadToolBar
>
</
Grid
>
The RadWindow is generated from managed code and it's content is set to this usercontrol. If I simply remove the RadDropDownButton the usercontrol is GC. I keep weak references to all RadWindows and usercontrols in our code and everywhere there is a RadDropDown or RadComboBox nothing is GC.
I clicked two cleanup button, then I click check button. When RadWindow is dead, team of telerik can help me solved memory leak problem. My application run first using 192MB ram, then I open RadWindow. My ram for iexplore is 268MB. After I closed RadWindow and next record in my radgridview. I reopen with edit mode, my ram for iexplore is 320MB. After about 5 time, my ram for iexplore is 630MB.
Thank you for reporting this. We've reproduced it and already fixed it. The fix will be available with the upcoming Service Pack 2 release.
Thank you once again for the report and for your patience.
Miro Miroslavov
the Telerik team
Most probably SP2 will be released next week.
Kind regards,
Milan
the Telerik team
Version Notes
RadControls for Silverlight 2010.2 924
Subscribe for the telerik Product Updates RSS feed
I notice the caption is Q1 2010 SP2 .. Q1 2010 Sp2 was back in june ... assume as version is 2010.2 xxx that this is a typo ?
Did this release include a workaround/fix for the memory leak issues with radcombobox, presumably caused by the silverlight popup leak ? Our initial cursory tests seem to indicate the RadComboBox still leaks, I'd like to know if this was considered fixed before I do a detailed test or a repo.
Yes this is a typo. Excuse us for the confusion. The Q2 2010 SP2 is released and its version is 2010.2.0924.
With this service pack we addressed all known issues related to Template binding to a custom dependency property in a Popup’s Content and Inline DataTemplate, instantiated via DataTemplate.LoadContent() method.
Please upgrade your project and let us know if you encounter any issues.
Regards,
Hristo
the Telerik team
With problem memory leaks of radwindow when closed window, memory not released. You can guide line me about RadWindow, can you?
I would suggest you to refer to the following forum thread - http://www.telerik.com/community/forums/silverlight/window/leak-memory-on-radwindow.aspx
I hope this sheds some light on the problem. If you still have any memory issues with our RadControls, please feel free to let us know.
George
the Telerik team
Thank you guys for the hard work you've put into this.
Best regards,
Manuel FelĂcio.
Moving the DataTemplate to a StaticResource didn't do it for me. What did seem to help was to ditch the XAML DataTemplate altogether, as I created a custom Column class that inherits from GridViewColumn. I then put together the Framework Elements in the code-behind for the GridView column. This seems to be captured by the GarbageCollector and taken care of.
public class MyCustomColumn : Telerik.Windows.Controls.GridViewColumn
{
public override FrameworkElement CreateCellElement(Telerik.Windows.Controls.GridView.GridViewCell cell, object dataItem)
{
// Build it here in the code-behind
}
}
We had similar problem however this is already fixed in our latest build.
Kind regards,Vlad
the Telerik team