Last Updated: 05 Apr 2021 05:02 by ADMIN
Release LIB 2021.1.405 (5/04/2021)
Created on: 12 Mar 2021 13:31
Category: UI for WPF
Type: Bug Report
RadTileList Memory leak

We use a RadTileList as our main navigation component. Today we noticed that our app's memory consumption only ever increases when opening modules and never decreases when closing them. When tracing memory usage with DotMemory (using the Key retention paths feature), I noticed that the retention path to the leaked module viewmodels seems to be rooted in the RadTileList component (see the attached screen shot).

A few implementation details:

- We are wrapping our modules in a class called "OpenedModule" (as you might guess from the attached image)

- The RadTileList is databound to an ObservableCollection<OpenedModule> via its ItemsSource

- We do not use grouping

- Closing a module results in the module's "OpenedModule" instance being removed from the ObservableCollection

This is the xaml we use to instantiate the TileList:

    ItemsSource="{Binding OpenedModules, Mode=OneWay}" 
    ItemTemplate="{StaticResource NavigationTileListTemplate}">
         <Style TargetType="{x:Type telerik:Tile}" BasedOn="{StaticResource NavigationTileStyle}" />


Judging by the result from dotMemory, it looks like the TileGroup's children are somehow cached in an ordered list which is not updated when an item is removed?


Best Regards,

Simon Müller

Attached Files:
1 comment
Ivan Petrov
Posted on: 19 Mar 2021 10:37

Hi Simon,

Thank you for the provided details and the trace screenshot. They were of great help while investigating the issue.

The internal architecture of the RadTileList dictates that tiles are placed inside groups, and groups are placed inside RadTileList. This is why, in cases like yours where no grouping is used, we internally create a default group to hold all tiles. Furthermore, each group has a collection of tiles and a collection of the same tiles ordered by their display index. Here is where the memory leak stems from. The latter collection, where the tiles are ordered, is not properly synchronized with the former when tiles are removed from it. Your case perfectly exemplifies this incorrect behavior and brings it to the front. 

I have also updated your Telerik Points for bringing this issue to our attention. 

If I can assist you further, do not hesitate to write back.

Ivan Petrov
Progress Telerik

Love the Telerik and Kendo UI products and believe more people should try them? Invite a fellow developer to become a Progress customer and each of you can get a $50 Amazon gift voucher.