DateTimePicker is leaking

ADMIN

Petar Marchev

Posted on: 08 Feb 2021 10:53

Hi Robert,

In general we see memory leaks as huge problems and we do try our best to minimize such issues. In the given setup I do not think there is a memory leak and I will explain below why I think that.

We have internal tests and a built in MemoryTracker to help us identify memory issues. We also use the VS profiler to look for such things. With both of these I am unable to find a problem in neither our internal ui-tests, nor in the application that Yana sent to you (BlankApp1).

I think that what is going on is that you conduct the test too quickly and the runtime doesn't find a convenient enough time to properly run the GC and release the resources.

What I mean with the previous sentence is this - if you take a snapshot too quickly after navigating back from the PopupPage, then the runtime might not have released resources that would otherwise be released. I did see that in my tests, actually. One of the times, I rushed the test, and indeed, the Snapshot contained instances that should not be alive. However, with a consequent Snapshot, the instances were garbage-collected.

So what I can suggest for you is to try the BlankApp1_Modified, and let some time pass before taking a snapshot. What I did was to open few popups, and then navigate a couple of times back-and-forth to the PopupPage and not-open the picker's popup. Then I waited some seconds, then Forced collection via the profiler, and then took a snapshot. With that test, no instances were left alive.

For even a more thorough test I used WeakReferences. I am sending a modified version of the BlankApp1, where I added some things in the PopupPage.

I save a weak reference for each RadDateTimePicker created. I also used implicit styles and a custom Helper class to track SpinnerItemView instances. I used the SpinnerItemView as I can see them left alive in the snapshots you provided, and because the spinner-item-view is an element that is somewhere deep inside the Popup. So, if this element is released, then all the Popup and all of its content is released.

So, I modified the example to print in the Output window, if and how many instances are left alive. I am also attaching a snapshot with my measurements, for your reference.

In this test (dtp_output.png) I did the following - navigated the PopupPage four times without opening the popup, then 1 time I opened the popup, and repeated that sequence two more times. During this, I was keeping an eye in the output and saw that every time the popup opened, about 18 new instances of SpinnerItemView were created. The last time I navigated to the PopupPage, the output displayed that there were no alive instances left of either the RadDateTimePicker, or the SpinnerItemView. But the time before that - there were instances that were not yet garbage collected. So as I mentioned, this is only because the runtime did not find the time to release the instances right away, but it eventually did.

I did a similar test with the VS profiler, with similar results, but I decided not to send more snapshots and explanations as this post is already getting very large and complicated.

In conclusion, with both of the WeakReference-test and vs-profiler-test in mind, I did not find anything suspicious in the date time picker. All instances were eventually collected. This is why I say with confidence that there is no memory leak in the BlankApp1 and its modification.

Again, I will suggest for you to test the modified version, and do both tests, as I did. One test with the WeakReferences and the output window, and another test with the vs-profiler. If you see some instances alive, just give it a little more time, navigate once or twice to the PopupPage without openinng the popup, and this should give the runtime enough opportunity to release all instances.

Also keep in mind that every time the popup gets opened, about 17-18 new instances are created of the SpinnerItemView. So if these instances were leaking, after a few popups being opened, the number of alive SpinnerItemViews would accumulate to hundreds, and not just 17-18.

Please conduct the tests as I suggested and let us know if you observe the same results on your side, or if you get different measurements. As I mentioned earlier, we don't like having any memory issues, and I might have missed something, and we will be happy if you help us identify something I was not able to.

Thank you for your help and understanding.

Regards,
Petar Marchev
Progress Telerik

Virtual Classroom, the free self-paced technical training that gets you up to speed with Telerik and Kendo UI products quickly just got a fresh new look + new and improved content including a brand new Blazor course! Check it out at https://learn.telerik.com/.

Attached Files:

Robert

Posted on: 03 Feb 2021 10:00

Also, yes, it leaks in release builds too :)

Robert

Posted on: 03 Feb 2021 09:46

Hello Yana,

I have tried your example, and I'm not sure what to think...

These are a bunch of snapshots I have taken to test your sample app. It was first pre-warmed a couple of times (popup opened, datepicker popup opened, closed, etc), and then I have started to take snapshots.

The snapshots are a lot of various combinations of just opening the popup page and closing it, or opening the popup page, then the datepicker spinner popup and dismissing it, or everything together. Everything was let to rest for a while, between snapshots 12 and 13, and then the process was repeated.

The last snapshot is 55k objects and 2.6 MB of memory, compared to 19k and 1.2 MB at the baseline.

There's a lot of stuff when snapshot 23 is compared to snapshot 1... Here's what I found under Telerik.*:

Telerik.XamarinForms.Common.Animations.DoubleAnimationTask +8 +1.280 +1.472 8 1.280 1.472
Telerik.XamarinForms.Common.AppThemeColorHelper +2 +72 +848 2 72 848
Telerik.XamarinForms.Common.BindablePropertyExtensions+RendererChangedEventHandler +14 +448 +448 14 448 448
Telerik.XamarinForms.Common.CommandCollection<Telerik.XamarinForms.Primitives.RadSlideViewPresenter> +2 +72 +120 2 72 120
Telerik.XamarinForms.Common.HelpTextEffect +4 +96 +176 4 96 176
Telerik.XamarinForms.Common.InteractionManager.PanInertiaCalculator +6 +72 +9.504 6 72 9.504
Telerik.XamarinForms.Common.LayoutControl.HorizontalLayoutControlPanelStrategy +2 +112 +528 2 112 528
Telerik.XamarinForms.Common.LayoutControl.LayoutControlPanelChildTuple +2 +56 +56 2 56 56
Telerik.XamarinForms.Common.NativeGestureRecognizer +10 +560 +1.632 10 560 1.632
Telerik.XamarinForms.Common.ObservableItemCollection<Telerik.XamarinForms.DataControls.SpinnerLayoutItem> +6 +312 +331.316 6 312 331.316
Telerik.XamarinForms.Common.ObservableItemCollection<Telerik.XamarinForms.Input.IDateComponent> +2 +104 +300.704 2 104 300.704
Telerik.XamarinForms.Common.ObservableItemCollection<Telerik.XamarinForms.Input.ISpinnerContext> +4 +208 +584 4 208 584
Telerik.XamarinForms.Common.ObservableItemCollection<Telerik.XamarinForms.Input.ITimeComponent> +2 +104 +392 2 104 392
Telerik.XamarinForms.Common.ObservableItemCollection<Telerik.XamarinForms.Primitives.TabViewHeaderItem> +2 +104 +880 2 104 880
Telerik.XamarinForms.Common.ObservableItemCollection<Telerik.XamarinForms.Primitives.TabViewItem> +2 +104 +2.620 2 104 2.620
Telerik.XamarinForms.Common.ObservableItemCollection<Telerik.XamarinForms.Primitives.Toolbar.PanelDisplayInfo> +2 +104 +90.080 2 104 90.080
Telerik.XamarinForms.Common.ObservableItemCollection<Telerik.XamarinForms.Primitives.ToolbarItemBase> +4 +208 +872 4 208 872
Telerik.XamarinForms.Common.ObservableItemCollection<Xamarin.Forms.View> +2 +104 +568 2 104 568
Telerik.XamarinForms.Common.RadAppThemeExtensions+RadAppThemeHelper +2 +32 +592 2 32 592
Telerik.XamarinForms.Common.RadAppThemeExtensions+RadAppThemeHelper+ThemedPropertyHelper<Xamarin.Forms.Color> +2 +168 +168 2 168 168
Telerik.XamarinForms.Common.RadDoubleAnimation +8 +288 +2.016 8 288 2.016
Telerik.XamarinForms.Common.TouchManager+PanEventHandler +6 +192 +192 6 192 192
Telerik.XamarinForms.Common.TouchManager+TapEventHandler +8 +256 +256 8 256 256
Telerik.XamarinForms.Common.TouchManager+WheelEventHandler +6 +192 +192 6 192 192
Telerik.XamarinForms.Common.UWP.RadViewContainer +4 +176 +272 4 176 272
Telerik.XamarinForms.DataControls.RadSpinner +6 +1.944 +1.228.392 6 1.944 1.228.392
Telerik.XamarinForms.DataControls.SpinnerItemView +31 +9.424 +1.404.012 31 9.424 1.404.012
Telerik.XamarinForms.DataControls.SpinnerLayoutItem +31 +2.480 +329.764 31 2.480 329.764
Telerik.XamarinForms.DataControls.SpinnerLayoutView +6 +1.728 +1.296.176 6 1.728 1.296.176
Telerik.XamarinForms.DataControls.SpinnerScrollHandler +6 +432 +12.024 6 432 12.024
Telerik.XamarinForms.DataControls.SpinnerVerticalLoopingStrategy +6 +96 +96 6 96 96
Telerik.XamarinForms.Input.DateSelectorViewModel +2 +192 +301.504 2 192 301.504
Telerik.XamarinForms.Input.DateTimeSelectorTabStripItem +2 +760 +80.352 2 760 80.352
Telerik.XamarinForms.Input.DateTimeSelectorViewModel +2 +168 +302.696 2 168 302.696
Telerik.XamarinForms.Input.PickerDateTimeSelector +2 +584 +631.208 2 584 631.208
Telerik.XamarinForms.Input.PickerPlaceholderView +2 +544 +28.720 2 544 28.720
Telerik.XamarinForms.Input.PickerPopupContentView +2 +544 +51.812 2 544 51.812
Telerik.XamarinForms.Input.PickerPopupFooterView +2 +544 +55.244 2 544 55.244
Telerik.XamarinForms.Input.PickerPopupHeaderView +2 +544 +38.372 2 544 38.372
Telerik.XamarinForms.Input.PickerPopupPresenter +2 +72 +118.016 2 72 118.016
Telerik.XamarinForms.Input.PickerPopupSelectorSettings +2 +192 +122.784 2 192 122.784
Telerik.XamarinForms.Input.RadDateTimePicker +2 +600 +111.832 2 600 111.832
Telerik.XamarinForms.Input.SpinnerDayViewModel +2 +144 +74.296 2 144 74.296
Telerik.XamarinForms.Input.SpinnerFormatParser +4 +48 +48 4 48 48
Telerik.XamarinForms.Input.SpinnerMonthViewModel +2 +152 +155.112 2 152 155.112
Telerik.XamarinForms.Input.SpinnerViewFactory +2 +24 +24 2 24 24
Telerik.XamarinForms.Input.SpinnerViewModelFactory +2 +32 +56 2 32 56
Telerik.XamarinForms.Input.SpinnerYearViewModel +2 +152 +70.848 2 152 70.848
Telerik.XamarinForms.Input.TimeSelectorViewModel +2 +136 +856 2 136 856
Telerik.XamarinForms.Primitives.PlacementHelper +2 +224 +224 2 224 224
Telerik.XamarinForms.Primitives.PlacementMode +2 +24 +24 3 36 36
Telerik.XamarinForms.Primitives.RadBorder +18 +5.472 +211.688 18 5.472 211.688
Telerik.XamarinForms.Primitives.RadPopup +2 +288 +4.636 2 288 4.636
Telerik.XamarinForms.Primitives.RadSlideView +2 +568 +818.456 2 568 818.456
Telerik.XamarinForms.Primitives.RadSlideViewPresenter +2 +536 +27.784 2 536 27.784
Telerik.XamarinForms.Primitives.RadTabView +2 +704 +766.656 2 704 766.656
Telerik.XamarinForms.Primitives.SlideView.Commands.SlideViewCommandService +2 +40 +256 2 40 256
Telerik.XamarinForms.Primitives.SlideView.PreservingContentManager +2 +88 +192 2 88 192
Telerik.XamarinForms.Primitives.SlideView.SlideViewIndicators +2 +568 +12.936 2 568 12.936
Telerik.XamarinForms.Primitives.SlideViewLabel +4 +944 +20.520 4 944 20.520
Telerik.XamarinForms.Primitives.TabViewHeader +2 +744 +121.372 2 744 121.372
Telerik.XamarinForms.Primitives.TabViewItem +2 +96 +2.172 2 96 2.172
Telerik.XamarinForms.Primitives.Toolbar.ItemsPanelsLayout<Telerik.XamarinForms.Primitives.TabViewHeaderItem> +2 +584 +97.976 2 584 97.976
Telerik.XamarinForms.Primitives.Toolbar.PanelDisplayInfo +4 +80 +80 4 80 80
Telerik.XamarinForms.Primitives.Toolbar.ToolbarItemsAdapter<Telerik.XamarinForms.Primitives.TabViewHeaderItem> +2 +32 +32 2 32 32
Telerik.XamarinForms.Primitives.Toolbar.ToolbarItemsPanel +2 +616 +89.144 2 616 89.144
Telerik.XamarinForms.PrimitivesRenderer.UWP.BorderRenderer +43 +4.644 +1.077.348 43 4.644 1.077.348
Telerik.XamarinForms.PrimitivesRenderer.UWP.TabViewHeaderItemRenderer +1 +108 +108 1 108 108

As you can see, many of them are +2 or +4, which isn't a lot compared to many, many times the datepicker has been opened and closed (sadly, I haven't tracked the exact count)... Some changes, however, stand out a lot:

Telerik.XamarinForms.DataControls.SpinnerItemView +31 +9.424 +1.404.012 31 9.424 1.404.012
Telerik.XamarinForms.DataControls.SpinnerLayoutItem +31 +2.480 +329.764 31 2.480 329.764
Telerik.XamarinForms.Primitives.RadBorder +18 +5.472 +211.688 18 5.472 211.688
Telerik.XamarinForms.PrimitivesRenderer.UWP.BorderRenderer +43 +4.644 +1.077.348 43 4.644 1.077.348

Have a look at this:

Or PropertyChangedEventHandler:

Or EventHandler:

Something isn't right.

Now let's compare that snapshot 2 (popup page simply opened and closed, no interaction with datepicker):

Don't know why the button and the grid are here, but it doesn't matter much. Nothing belonging to Telerik is in the list, which again means that simply having the DatePicker in the XAML is fine and won't cause any leaks; opening the spinner popup creates bad things that won't get disposed down the line. It's exactly the same as in our app.

If you look again at the comment I posted on Jan 22nd that includes just 3 times I opened and closed the spinner popup, something immediately stands out:

Telerik.XamarinForms.DataControls.SpinnerItemView +7 +2.128 +79.444 28 8.512 318.320
Telerik.XamarinForms.DataControls.SpinnerLayoutItem +7 +560 +80.312 28 2.240 321.792
Telerik.XamarinForms.Primitives.RadBorder +3 +912 +35.676 60 18.240 609.032
Telerik.XamarinForms.PrimitivesRenderer.UWP.BorderRenderer +12 +1.296 +2.976 54 5.832 12.552

Maybe those are not the source of the leak, just a consequence, I don't know, but something is definitely still leaking. Maybe have a look at the spinner control?

ADMIN

Yana

Posted on: 02 Feb 2021 08:38

Hi Robert,

Thank you for describing in details the case you have. I have tried to recreate the scenario in a simpler Prism project, still, I am missing a few bits (how the view model of the popup page is connected to the main page). I have attached my test app, would it be possible for you to download it and modify it, so that it resembles as much as possible the real setup you have? We would need to have the exact scenario, so we can investigate the reported issue.

One more request - would it be possible for you to test whether there is still a leak if you build the solution in Release build configuration?

Thank you for your cooperation on this.

Regards,
Yana
Progress Telerik

Virtual Classroom, the free self-paced technical training that gets you up to speed with Telerik and Kendo UI products quickly just got a fresh new look + new and improved content including a brand new Blazor course! Check it out at https://learn.telerik.com/.

Attached Files:

BlankApp1.zip

Robert

Posted on: 26 Jan 2021 09:09

Hello Yana,

In this scenario we're using Prism with Rg.Plugins.Popup, and the datepickers (two) are shown in a modal dialog:

Closing the dialog (that's basically what you suggested, to navigate away) creates no leaks whatsoever:

The changes are simple weak references that will get collected:

This is what happens when we open the datepicker popups (I opened both this time) and cancel out of both the datepicker popup and the modal dialog:

Not opening datepicker popups: fine

Opening datepicker popups: leak

The entries you see on the app screen snippet above are MaskedInputs and they are interconnected with DateTimePickers (through ApplyMaskFinished and SelectionChanged), so to exclude problems being having something to do with that and the controls' events, I have removed all codebehind and simplified the DateTimePickers' XAML to the following, as simple as it can get:

<telerikInput:RadDateTimePicker x:Name="dateTimePickerFrom" Date="{Binding Parameter.DateFrom, Mode=TwoWay}" SpinnerFormat="dd/MM/yyyy" DisplayStringFormat="dd.MM.yyyy">
                    <telerikInput:RadDateTimePicker.SelectorSettings>
                        <telerikInput:PickerPopupSelectorSettings
                AcceptCommand="{Binding DatePickerAcceptCancelCommand}"
                CancelCommand="{Binding DatePickerAcceptCancelCommand}"
                />
                    </telerikInput:RadDateTimePicker.SelectorSettings>
                </telerikInput:RadDateTimePicker>

Same thing. Dismissing the modal dialog: no leaks. Opening the datepicker popup, dismissing it and dismissing the modal dialog: leaks. Tried again: leak.

As previously, slightly fewer objects in the second dismissal, but still huge.

GC is being called on modal dialog dismissal already, as can be seen by the two orange triangles on Process Memory.

ADMIN

Yana

Posted on: 25 Jan 2021 16:30

Hello Robert,

Thank you for sending the details.

I would need more information on how you've tested this, I am asking as if you just open/close the popup, it's expected some objects to stay longer. Can you try after showing/closing the popup to navigate to a different page, so that the current page is disposed, and then check the result?

Another test you can try is to add a button and manually call GC.Collect(); on the button click event - after that check whether any popup-related objects stay in memory.

I look forward to your reply.

Regards,
Yana
Progress Telerik

Virtual Classroom, the free self-paced technical training that gets you up to speed with Telerik and Kendo UI products quickly just got a fresh new look + new and improved content including a brand new Blazor course! Check it out at https://learn.telerik.com/.

Robert

Posted on: 22 Jan 2021 07:19

Hello,

We have tried R1 2021 and the control is still leaking.

The presence of the Date(Time)Picker in XAML is okay, but showing and closing the popup with the spinners creates a leak.

Snapshot comparison of the last one (7) to the first one (1) lists the following changes under the Telerik namespace:

(weak references like WeakEventListener and WeakReferenceWrap are filtered out from this list)

Telerik.XamarinForms.Common.Animations.DoubleAnimationTask +1 +160 +184 28 4.480 5.152
Telerik.XamarinForms.Common.AppThemeColorHelper +1 +36 +424 4 144 1.696
Telerik.XamarinForms.Common.BindablePropertyExtensions+RendererChangedEventHandler +1 +32 +32 52 1.664 1.664
Telerik.XamarinForms.Common.LayoutControl.LayoutControlPanelChildTuple +1 +28 +28 4 112 112
Telerik.XamarinForms.Common.NativeGestureRecognizer +1 +56 +272 36 2.016 5.440
Telerik.XamarinForms.Common.RadDoubleAnimation +1 +36 +252 28 1.008 7.056
Telerik.XamarinForms.Common.UWP.RadViewContainer +4 +176 +272 10 440 824
Telerik.XamarinForms.DataControls.SpinnerItemView +7 +2.128 +79.444 28 8.512 318.320
Telerik.XamarinForms.DataControls.SpinnerLayoutItem +7 +560 +80.312 28 2.240 321.792
Telerik.XamarinForms.Input.PickerPopupContentView +1 +272 +20.996 4 1.088 77.328
Telerik.XamarinForms.Input.PickerPopupFooterView +1 +272 +25.304 4 1.088 107.716
Telerik.XamarinForms.Input.PickerPopupHeaderView +1 +272 +13.428 4 1.088 66.212
Telerik.XamarinForms.Input.PickerPopupPresenter +1 +36 +31.780 4 144 122.260
Telerik.XamarinForms.Primitives.PlacementHelper +1 +112 +112 4 448 448
Telerik.XamarinForms.Primitives.PlacementMode +1 +12 +12 5 60 60
Telerik.XamarinForms.Primitives.RadBorder +3 +912 +35.676 60 18.240 609.032
Telerik.XamarinForms.Primitives.RadPopup +1 +144 +6.464 4 576 28.196
Telerik.XamarinForms.PrimitivesRenderer.UWP.BorderRenderer +12 +1.296 +2.976 54 5.832 12.552

There are multiple objects whose count doesn't change, but memory usage does; it would be too much to paste all of that here and it's possible that GC would clear things eventually (not sure of that). Some examples, though:

Telerik.XamarinForms.Input.DateTimeSelectorViewModel 0 0 +100.600 8 672 830.812
Telerik.XamarinForms.Input.RadDateTimePicker 0 0 +204.732 8 2.400 2.349.776
Telerik.XamarinForms.Input.SpinnerDayViewModel 0 0 +49.788 8 416 444.204

ADMIN

Yana

Posted on: 27 Nov 2020 10:24

Hello Robert,

I understand, I am sorry to hear the workaround did not help. We will investigate the issue in details and hopefully will be able to provide a solution soon.

Regards,
Yana
Progress Telerik

Virtual Classroom, the free self-paced technical training that gets you up to speed with Telerik and Kendo UI products quickly just got a fresh new look + new and improved content including a brand new Blazor course! Check it out at https://learn.telerik.com/.

Robert

Posted on: 25 Nov 2020 11:27

Hi Yana,

We already programmed a method that traverses controls recursively and cleans up whatever it can (clears behaviors, binding contexts, gestures, calls Dispose if IDisposable, removes children, sets everything to null…) but unfortunately it doesn't help here :(

Probably there's an event handler internally left on your end and there's no way to remove it ourselves.

ADMIN

Yana

Posted on: 25 Nov 2020 09:30

Hi Robert,

We take this issue very seriously as it concerns memory usage and we're definitely planning to look into it with priority. We're going to update the feedback item here as soon as we have any new information on the matter.

In the meantime, as a temporary workaround, you can try to manually remove the DateTimePicker control from the visual tree when navigating away from the page.

I am so sorry for the caused inconvenience.

Regards,
Yana
Progress Telerik

Virtual Classroom, the free self-paced technical training that gets you up to speed with Telerik and Kendo UI products quickly just got a fresh new look + new and improved content including a brand new Blazor course! Check it out at https://learn.telerik.com/.

Robert

Posted on: 24 Nov 2020 09:12

Hello,

Are there any news regarding the leak?

In our scenario, we're seeing over 20.000 objects leaked for a couple of opened datepickers. Considering our app starts with 250.000 objects, and it's fairly complex at start with lots and lots of visual elements, this is quite bad.

ADMIN

Yana

Posted on: 18 Nov 2020 14:20

Hello Robert,

Indeed, there is an issue related to disposing the DataTimePicker instance - I confirm this is a bug on our side. I've updated the status of this item to "Unplanned", and hopefully we'll be able to provide a solution soon.

I've updated your points as a small sign of gratitude for reporting the issue to us. I am sorry for the caused inconvenience.

Regards,
Yana
Progress Telerik

Virtual Classroom, the free self-paced technical training that gets you up to speed with Telerik and Kendo UI products quickly just got a fresh new look + new and improved content including a brand new Blazor course! Check it out at https://learn.telerik.com/.