As most of the people doing XAML development already know Silverlight 4 shipped at Mix 10 this year. This official release contained a lot of issues (memory leaks included) and it was a reasonable decision for Microsoft to postpone their GDR (general distribution release – the one that comes with Windows Update) version. A few weeks ago, Microsoft finally shipped the GDR. One of the things all developers hoped for was a resolution to the known memory leaks. The GDR did fix a lot of memory leaks, however, it did not address all of them and there are still some with a severe impact.
We have identified and reported to Microsoft two major memory leaks in Silverlight 4 GDR:
Before answering how we have addressed these issues let’s look at what is the impact of each of them. The first issue’s impact was huge. A lot of our controls were using Popup’s including: RadComboBox, RadMenu, RadRibbonBar, many buttons and pickers. If you have just used any of these controls without even data-binding it is going to leak. Not only the control itself will leak, but the whole page that the control is used into will leak, because it has a strong reference to the control. Regarding the second issue the main control that was affected was RadGridView, because it allows users to customize each column’s appearance via data templates. Fortunately Microsoft have provided early on an “official workaround” to use Static Resources instead of inline data template definition. This will require a change on your side, but after all it is a doable operation.
Microsoft did acknowledge both problems (SL forums) and Tim Heuer said that they do have a fix but he could not commit to when an update (or another GDR) will be available. As customers were experiencing a lot of pain with this (TELERIK forums), and we were affected internally as a number of Telerik products such as TeamPulse heavily utilize Silverlight, we decided to take immediate action regardless of the enormous effort involved.
Luckily, our team has been successful in fixing both of the above runtime memory leaks in the Telerik code base:
Memory leaks are one of the nastiest problems you can have in an application and we’d like to spare our customers. While we did save the day, the more important question is how do we ensure this does not happen again (or can we even make such a claim?). In order to prevent future memory leaks we have developed our own micro unit tests framework that covers all of the above leaking scenarios. We are going to expand these unit tests covering more and more use cases in the future.
We have always tried to stay close to our customer and address their problems early on. In this ongoing process we have introduced the concept of Latest Internal Build which allows you an early access to our internal continues integration builds containing fixes that you have reported.
We have pushed a new official service pack release which will have all known memory leak fixes packed. We know the high price for fixing a bug and this is the reason we have delayed this servicing release. Rushing to the first working solution and not evaluating other possible approaches that we might have taken is something that we will not do. As you know the only way to go fast is to go right. You can download the latest files under your accounts' Downloads - RadControls for Silverlight section
If any customer experiences further memory leak issues, please share your comment here or at the forum thread that I listed above.As Chief Innovation Officer at Progress, Vassil Terziev is responsible for identifying growth strategies and new market opportunities, as well as promoting internal innovation.