Navigation memory leak: Appearing event not being unsubscribed properly #24507

mattsetaro · 2024-08-29T13:36:27Z

Description of Change

Capture the event being subscribed to Appearing in OnAppearing(Action) into a file-scoped field, to be unsubscribed now in SendDisappearing().

The OnAppearing(Action) call in Page.cs was subscribing an event to the Appearing EventHandler, and not unsubscribing when navigating away, leading to memory leaks. Note the _invocationList count in the screenshot:

I also have gcdump's of a File>New MAUI application with two pages that navigate to each other automatically, reproducing the issue. Source code and gcdumps here: https://github.com/mattsetaro/MauiMemoryLeak

I was also able to reproduce the memory leak with a unit test, here is the unit test and a screenshot of the memory snapshot from dotMemory (Object[] from screenshot is _invocationList on the Appearing event):

[Fact]
public async void MemoryLeak()
{
    Routing.RegisterRoute("page1/page2", typeof(DummyPage));
    Routing.RegisterRoute("page1/page2/page3", typeof(DumberPage));
    
    var shell = new TestShell(
    CreateShellItem(shellSectionRoute: "page1")
    );
    
    int ctr = 0;
    while (true)
    {
        await shell.GoToAsync("page1/page2/page3");
        Assert.True(shell.CurrentPage is DumberPage);
        
        await shell.GoToAsync("..");
        Assert.True(shell.CurrentPage is DummyPage);
        
        if (++ctr % 1000 == 0)
        {
	    _testOutputHelper.WriteLine("Total memory: " + GC.GetTotalMemory(false).ToString("N0"));
        }
    }
}

class DummyPage : Page
{
}

class DumberPage : Page
{
}

Issues Fixed

mattsetaro · 2024-08-29T13:40:16Z

@dotnet-policy-service agree company="Intelligent Product Solutions" From: dotnet-policy-service[bot] ***@***.***> Date: Thursday, August 29, 2024 at 9:38 AM To: dotnet/maui ***@***.***> Cc: Matthew Setaro ***@***.***>, Mention ***@***.***> Subject: Re: [dotnet/maui] Navigation memory leak: Appearing event not being unsubscribed properly (PR #24507) @mattsetaro<https://github.com/mattsetaro> please read the following Contributor License Agreement(CLA). If you agree with the CLA, please reply with the following information. @dotnet-policy-service agree [company="{your company}"] Options: * (default - no company specified) I have sole ownership of intellectual property rights to my Submissions and I am not making Submissions in the course of work for my employer. @dotnet-policy-service agree * (when company given) I am making Submissions in the course of work for my employer (or my employer has intellectual property rights in my Submissions by contract or applicable law). I have permission from my employer to make Submissions and enter into this Agreement on behalf of my employer. By signing below, the defined term “You” includes me and my employer. @dotnet-policy-service agree company="Microsoft" Contributor License Agreement Contribution License Agreement This Contribution License Agreement ( “Agreement” ) is agreed to by the party signing below ( “You” ), and conveys certain license rights to the .NET Foundation ( “.NET Foundation” ) for Your contributions to .NET Foundation open source projects. This Agreement is effective as of the latest signature date below. 1. Definitions. “Code” means the computer software code, whether in human-readable or machine-executable form, that is delivered by You to .NET Foundation under this Agreement. “Project” means any of the projects owned or managed by .NET Foundation and offered under a license approved by the Open Source Initiative (www.opensource.org<http://www.opensource.org/>). “Submit” is the act of uploading, submitting, transmitting, or distributing code or other content to any Project, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Project for the purpose of discussing and improving that Project, but excluding communication that is conspicuously marked or otherwise designated in writing by You as “Not a Submission.” “Submission” means the Code and any other copyrightable material Submitted by You, including any associated comments and documentation. 2. Your Submission. You must agree to the terms of this Agreement before making a Submission to any Project. This Agreement covers any and all Submissions that You, now or in the future (except as described in Section 4 below), Submit to any Project. 3. Originality of Work. You represent that each of Your Submissions is entirely Your original work. Should You wish to Submit materials that are not Your original work, You may Submit them separately to the Project if You (a) retain all copyright and license information that was in the materials as you received them, (b) in the description accompanying your Submission, include the phrase "Submission containing materials of a third party:" followed by the names of the third party and any licenses or other restrictions of which You are aware, and (c) follow any other instructions in the Project's written guidelines concerning Submissions. 4. Your Employer. References to “employer” in this Agreement include Your employer or anyone else for whom You are acting in making Your Submission, e.g. as a contractor, vendor, or agent. If Your Submission is made in the course of Your work for an employer or Your employer has intellectual property rights in Your Submission by contract or applicable law, You must secure permission from Your employer to make the Submission before signing this Agreement. In that case, the term “You” in this Agreement will refer to You and the employer collectively. If You change employers in the future and desire to Submit additional Submissions for the new employer, then You agree to sign a new Agreement and secure permission from the new employer before Submitting those Submissions. 5. Licenses. a. Copyright License. You grant .NET Foundation, and those who receive the Submission directly or indirectly from .NET Foundation, a perpetual, worldwide, non-exclusive, royalty-free, irrevocable license in the Submission to reproduce, prepare derivative works of, publicly display, publicly perform, and distribute the Submission and such derivative works, and to sublicense any or all of the foregoing rights to third parties. b. Patent License. You grant .NET Foundation, and those who receive the Submission directly or indirectly from .NET Foundation, a perpetual, worldwide, non-exclusive, royalty-free, irrevocable license under Your patent claims that are necessarily infringed by the Submission or the combination of the Submission with the Project to which it was Submitted to make, have made, use, offer to sell, sell and import or otherwise dispose of the Submission alone or with the Project. c. Other Rights Reserved. Each party reserves all rights not expressly granted in this Agreement. No additional licenses or rights whatsoever (including, without limitation, any implied licenses) are granted by implication, exhaustion, estoppel or otherwise. 6. Representations and Warranties. You represent that You are legally entitled to grant the above licenses. You represent that each of Your Submissions is entirely Your original work (except as You may have disclosed under Section 3 ). You represent that You have secured permission from Your employer to make the Submission in cases where Your Submission is made in the course of Your work for Your employer or Your employer has intellectual property rights in Your Submission by contract or applicable law. If You are signing this Agreement on behalf of Your employer, You represent and warrant that You have the necessary authority to bind the listed employer to the obligations contained in this Agreement. You are not expected to provide support for Your Submission, unless You choose to do so. UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING, AND EXCEPT FOR THE WARRANTIES EXPRESSLY STATED IN SECTIONS 3, 4, AND 6 , THE SUBMISSION PROVIDED UNDER THIS AGREEMENT IS PROVIDED WITHOUT WARRANTY OF ANY KIND, INCLUDING, BUT NOT LIMITED TO, ANY WARRANTY OF NONINFRINGEMENT, MERCHANTABILITY, OR FITNESS FOR A PARTICULAR PURPOSE. 7. Notice to .NET Foundation. You agree to notify .NET Foundation in writing of any facts or circumstances of which You later become aware that would make Your representations in this Agreement inaccurate in any respect. 8. Information about Submissions. You agree that contributions to Projects and information about contributions may be maintained indefinitely and disclosed publicly, including Your name and other information that You submit with Your Submission. 9. Governing Law/Jurisdiction. This Agreement is governed by the laws of the State of Washington, and the parties consent to exclusive jurisdiction and venue in the federal courts sitting in King County, Washington, unless no federal subject matter jurisdiction exists, in which case the parties consent to exclusive jurisdiction and venue in the Superior Court of King County, Washington. The parties waive all defenses of lack of personal jurisdiction and forum non-conveniens. 10. Entire Agreement/Assignment. This Agreement is the entire agreement between the parties, and supersedes any and all prior agreements, understandings or communications, written or oral, between the parties relating to the subject matter hereof. This Agreement may be assigned by .NET Foundation. .NET Foundation dedicates this Contribution License Agreement to the public domain according to the Creative Commons CC0 1. — Reply to this email directly, view it on GitHub<#24507 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AWUVGJ56GINOXZ7IMNKARR3ZT4P5BAVCNFSM6AAAAABNKOSVQ2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMJXGY4DMNBSGU>. You are receiving this because you were mentioned.Message ID: ***@***.***>

PureWeen · 2024-08-29T14:52:01Z

/azp run

azure-pipelines · 2024-08-29T14:52:22Z

Azure Pipelines successfully started running 3 pipeline(s).

src/Controls/src/Core/Page/Page.cs

PureWeen · 2024-08-29T16:37:10Z

/azp run

azure-pipelines · 2024-08-29T16:37:30Z

Azure Pipelines successfully started running 3 pipeline(s).

jonathanpeppers · 2024-08-29T20:45:31Z

src/Controls/tests/Core.UnitTests/PageTests.cs

+		[Fact]
+		public void SendDisappearingUnsubscribesAppearingEvent()


I think the new test fails:

It was failing because the counter was not being reset, but I discovered it was not really reproducing the issue correctly so I will look into that today

mattleibow

@PureWeen is this fix a good thing, or are we hiding a more sinister issue that should never happen?

Otherwise, this looks like a good fix to a possible real-world scenario?

mattleibow · 2024-09-02T20:18:35Z

src/Controls/tests/Core.UnitTests/PageTests.cs

+			// This subscribes the event if the page has not appeared already
+			int invokeCounter = 0;
+			navPage.OnAppearing(() => { invokeCounter++; });
+			((IPageController)navPage).SendAppearing();
+			Assert.Equal(1, invokeCounter);
+
+			// Navigate away
+			((IPageController)navPage).SendDisappearing();
+
+			// This should not increment the counter when navigating back
+			navPage.OnAppearing(() => { invokeCounter++; });
+			((IPageController)navPage).SendAppearing();
+			Assert.Equal(1, invokeCounter);


This may work better:

Suggested change

// This subscribes the event if the page has not appeared already

int invokeCounter = 0;

navPage.OnAppearing(() => { invokeCounter++; });

((IPageController)navPage).SendAppearing();

Assert.Equal(1, invokeCounter);

// Navigate away

((IPageController)navPage).SendDisappearing();

// This should not increment the counter when navigating back

navPage.OnAppearing(() => { invokeCounter++; });

((IPageController)navPage).SendAppearing();

Assert.Equal(1, invokeCounter);

// This subscribes the event if the page has not appeared already

page.OnAppearing(() => Assert.Fail("Previous OnAppearing event code ran when it should have been removed."));

// Navigate away BEFORE a navigation TO completes

((IPageController)navPage).SendDisappearing();

// This should not increment the counter when navigating back

((IPageController)navPage).SendAppearing();

But it still does not work and I am going to bed. :)

But basically, you are calling SendAppearing which will always trigger and then unsub the event, so maybe you should skip the first SendAppearing to emulate? Or maybe this issue is a bit different? Might need to finish my nap before I fully understand this issue.

yeah I was seeing something similar on my end too, will look into it today, thanks I like that Assert.Fail()

mattleibow · 2024-09-02T20:20:45Z

src/Controls/src/Core/Page/Page.cs

+		EventHandler _onAppearingEventHandler;
 		internal void OnAppearing(Action action)


@PureWeen not sure if it is ever the case where multiple callers will invoke this method before it appears and thus we need some sort of list of actions to run once it appears?

Maybe some list of actions is better anyway and a single event handler that just runs all the actions. And the disappearing just clears the list? Like a list of pending onappearing actions? For example, we have the _pendingActions list for the alerts and popups, so maybe we need to have a list of things that run once the page appears?

mattsetaro · 2024-09-03T14:28:53Z

@PureWeen @mattleibow @jonathanpeppers I have an interesting development on this PR. In trying to write a unit test that reproduces the issue not using an infinite loop, I discovered the root cause of the memory leak is actually from a race condition somewhere up higher in the call stack. With a debugger attached, my interpretation of the normal order of operations when calling Shell.GoToAsync() is Page.SendAppearing(), then Page.OnAppearing(Action), but once every so many iterations the execution order will be reversed, thusly causing the event to be subscribed and never unsubscribed.

I was able to find this out using the unit test I wrote which is not in the PR but in my initial post. You can see here that putting a breakpoint just below ln 623 in Page.cs only breaks for the first time when ctr has a value of 62 in this case:

... up the call stack...

With this in mind, my proposed changes will resolve the memory leak, but not the race condition causing the memory leak in the first place. I will continue to investigate the root cause of the race condition in the mean time.

mattsetaro · 2024-09-10T14:33:12Z

@PureWeen @jonathanpeppers @mattleibow Update for you three, sorry I haven't had much time to look at this recently. That said I am confident I was able to figure out the root cause for this issue. At some point the RealParent property on the active Window is getting garbage collected. Here's how I am able to confirm that and you can test for yourself:

Using the following unit test, place a breakpoint on Page.cs line 623 (the end of OnAppearing(Action) where the += is).

[Fact]
public async void MemoryLeak()
{
    Routing.RegisterRoute("page1/page2", typeof(DummyPage));
    Routing.RegisterRoute("page1/page2/page3", typeof(DumberPage));
    
    var shell = new TestShell(
    CreateShellItem(shellSectionRoute: "page1")
    );
    
    int ctr = 0;
    while (true)
    {
        await shell.GoToAsync("page1/page2/page3");
        Assert.True(shell.CurrentPage is DumberPage);
        
        await shell.GoToAsync("..");
        Assert.True(shell.CurrentPage is DummyPage);
        
        if (++ctr % 1000 == 0)
        {
	    _testOutputHelper.WriteLine("Total memory: " + GC.GetTotalMemory(false).ToString("N0"));
        }
    }
}

class DummyPage : Page
{
}

class DumberPage : Page
{
}

Run the unit test, when the breakpoint hits, jump down the call stack to the above unit test and make note of the ctr value, as it should be greater than 0, in my case somewhere between 55-65, meaning we haven't gotten to the event += until 50 iterations of the loop, or about 100 navigations. Hit play to resume the unit test, and jump down the call stack again to note the value of ctr should be += 1. This should be the behavior for every iteration moving forwards.

Now add in another breakpoint on Element.cs line 353 (the else condition of the getter of RealParent) and restart the test. When running the test, note that the breakpoint in Element.cs breaks BEFORE the original breakpoint in Page.cs.

With the breakpoint broken inElement.cs jump down the call stack again to the unit test again and make note of the ctr value. Remove the breakpoint in Element.cs and resume execution. Note the Page.cs breakpoint should break immediately, and if you jump down the call stack and look at the value of ctr it should be the same as when the breakpoint in Element.cs broke. From there on out, the Page.cs breakpoint will break every navigation attempt.

This test confirms that the Window.Parent.RealParent is being garbage collected at some point. Now I am not that familiar with the framework's code as I only just started looking at it with this effort, so I can't help but think I am mocking something incorrectly, or the test/mock Window or Shell code is not set up properly. If one of you are able to confirm or deny that I would appreciate it.

In the mean time I will look into why the RealParent is being garbage collected. Thanks

mattsetaro · 2024-09-10T16:02:56Z

@PureWeen @jonathanpeppers @mattleibow I added in some changes that do fix the issue of the RealParent property being garbage collected. That said I have not worked much with WeakReference and would appreciate feedback on the new changes. Thanks

mattsetaro · 2024-09-19T20:06:56Z

@PureWeen @jonathanpeppers @mattleibow I understand you three are probably very busy but we are trying to test if these changes will fix a memory leak for a client's project. If you can look at the PR and or assist in creating a pre-release build to test with I would really appreciate it.

PureWeen · 2024-09-20T14:33:54Z

/azp run

azure-pipelines · 2024-09-20T14:34:19Z

Azure Pipelines successfully started running 3 pipeline(s).

PureWeen · 2024-09-20T14:37:05Z

/rebase

PureWeen · 2024-09-20T14:39:04Z

src/Controls/src/Core/Element/Element.cs

@@ -280,6 +280,7 @@ internal bool RemoveLogicalChild(Element element, int index)

 		internal bool Owned { get; set; }

+		Element _strongParentOverrideReference;


This is going to break other scenarios with memory leaks. The main point of the weakreference on the Parent is to avoid circular references on iOS which cause things to not get collected. So, we'll need to understand a bit more about why the Parent here is getting collected at all.

The parent should ideally be rooted to something so that doesn't happen, but it looks like there's probably a scenario we're not accounting for

PureWeen · 2024-09-20T16:24:05Z

@PureWeen @jonathanpeppers @mattleibow Update for you three, sorry I haven't had much time to look at this recently. That said I am confident I was able to figure out the root cause for this issue. At some point the RealParent property on the active Window is getting garbage collected. Here's how I am able to confirm that and you can test for yourself:

Using the following unit test, place a breakpoint on Page.cs line 623 (the end of OnAppearing(Action) where the += is).
[Fact]
public async void MemoryLeak()
{
    Routing.RegisterRoute("page1/page2", typeof(DummyPage));
    Routing.RegisterRoute("page1/page2/page3", typeof(DumberPage));
    
    var shell = new TestShell(
    CreateShellItem(shellSectionRoute: "page1")
    );
    
    int ctr = 0;
    while (true)
    {
        await shell.GoToAsync("page1/page2/page3");
        Assert.True(shell.CurrentPage is DumberPage);
        
        await shell.GoToAsync("..");
        Assert.True(shell.CurrentPage is DummyPage);
        
        if (++ctr % 1000 == 0)
        {
	    _testOutputHelper.WriteLine("Total memory: " + GC.GetTotalMemory(false).ToString("N0"));
        }
    }
}

class DummyPage : Page
{
}

class DumberPage : Page
{
}
Run the unit test, when the breakpoint hits, jump down the call stack to the above unit test and make note of the `ctr` value, as it should be greater than 0, in my case somewhere between 55-65, meaning we haven't gotten to the event += until 50 iterations of the loop, or about 100 navigations. Hit play to resume the unit test, and jump down the call stack again to note the value of `ctr` should be += 1. This should be the behavior for every iteration moving forwards.
Now add in another breakpoint on Element.cs line 353 (the else condition of the getter of RealParent) and restart the test. When running the test, note that the breakpoint in Element.cs breaks BEFORE the original breakpoint in Page.cs.

With the breakpoint broken inElement.cs jump down the call stack again to the unit test again and make note of the ctr value. Remove the breakpoint in Element.cs and resume execution. Note the Page.cs breakpoint should break immediately, and if you jump down the call stack and look at the value of ctr it should be the same as when the breakpoint in Element.cs broke. From there on out, the Page.cs breakpoint will break every navigation attempt.

This test confirms that the Window.Parent.RealParent is being garbage collected at some point. Now I am not that familiar with the framework's code as I only just started looking at it with this effort, so I can't help but think I am mocking something incorrectly, or the test/mock Window or Shell code is not set up properly. If one of you are able to confirm or deny that I would appreciate it.

In the mean time I will look into why the RealParent is being garbage collected. Thanks

I tested this locally and for me the RealParent that gets collected is the testWindow and testApp because those were going out of scope and then getting collected.

I've pushed up a small change to TestWindow and TestApp and now with the weak references it never takes that path with the realparent

Also, your SendDisappearingUnsubscribesAppearingEvent isn't passing for me based on your latest changes

PureWeen · 2024-09-20T17:03:49Z

@mattsetaro I'm running your sample against the latest MAUI branch and I'm not seeing it subscribing to a bunch of appearing events anymore

mattsetaro · 2024-09-25T19:25:35Z

@PureWeen commit hash 68524c8 is still having leaking Page.Appearing subscriptions on my end:

using:

ShellUriHandlerTests.cs
[Fact]
public async void MemoryLeak()
{
    Routing.RegisterRoute("page1/page2", typeof(DummyPage));
    Routing.RegisterRoute("page1/page2/page3", typeof(DumberPage));
    
    var shell = new TestShell(
    CreateShellItem(shellSectionRoute: "page1")
    );
    
    int ctr = 0;
    while (true)
    {
        await shell.GoToAsync("page1/page2/page3");
        Assert.True(shell.CurrentPage is DumberPage);
        
        await shell.GoToAsync("..");
        Assert.True(shell.CurrentPage is DummyPage);
        
        if (++ctr % 1000 == 0)
        {
	    _testOutputHelper.WriteLine("Total memory: " + GC.GetTotalMemory(false).ToString("N0"));
        }
    }
}

class DummyPage : Page
{
}

class DumberPage : Page
{
}

Can you please verify your versions and how you tested it?

EDIT: If I add in the changes you committed to this PR to latest maui (for the TestShell and TestWindow) I don't see it leaking but does that mean this can never happen in a real-world scenario? I would like your opinion. Trying to figure out if we should move forward with fixing this. Thanks

sitecompass · 2024-10-09T00:08:15Z

Hello, just seeing when this one is looking to be resolved. Appreciate all the hard work that has gone into this thus far.

PureWeen · 2024-10-10T16:24:19Z

@PureWeen commit hash 68524c8 is still having leaking Page.Appearing subscriptions on my end:

using:
ShellUriHandlerTests.cs
[Fact]
public async void MemoryLeak()
{
    Routing.RegisterRoute("page1/page2", typeof(DummyPage));
    Routing.RegisterRoute("page1/page2/page3", typeof(DumberPage));
    
    var shell = new TestShell(
    CreateShellItem(shellSectionRoute: "page1")
    );
    
    int ctr = 0;
    while (true)
    {
        await shell.GoToAsync("page1/page2/page3");
        Assert.True(shell.CurrentPage is DumberPage);
        
        await shell.GoToAsync("..");
        Assert.True(shell.CurrentPage is DummyPage);
        
        if (++ctr % 1000 == 0)
        {
	    _testOutputHelper.WriteLine("Total memory: " + GC.GetTotalMemory(false).ToString("N0"));
        }
    }
}

class DummyPage : Page
{
}

class DumberPage : Page
{
}
Can you please verify your versions and how you tested it?

EDIT: If I add in the changes you committed to this PR to latest maui (for the TestShell and TestWindow) I don't see it leaking but does that mean this can never happen in a real-world scenario? I would like your opinion. Trying to figure out if we should move forward with fixing this. Thanks

The App and window get pretty rooted when running your application.

If the App or Window were to get GC'd out from under us you'd see hard crashes in the app not just memory leaks.

This might happen for embedding scenarios where the developer doesn't store a reference to the app or window. But even then the app and window are usually referenced by handlers and those handlers will be rooted to the visual tree which aren't going to get collected

mattsetaro requested a review from a team as a code owner August 29, 2024 13:36

mattsetaro requested review from Eilon and mattleibow August 29, 2024 13:36

dotnet-policy-service bot added the community ✨ Community Contribution label Aug 29, 2024

rmarinho requested review from jonathanpeppers and PureWeen and removed request for Eilon August 29, 2024 15:57

jonathanpeppers reviewed Aug 29, 2024

View reviewed changes

src/Controls/src/Core/Page/Page.cs Outdated Show resolved Hide resolved

src/Controls/src/Core/Page/Page.cs Show resolved Hide resolved

src/Controls/src/Core/Page/Page.cs Show resolved Hide resolved

mattsetaro requested a review from jonathanpeppers August 29, 2024 18:24

jonathanpeppers reviewed Aug 29, 2024

View reviewed changes

samhouts added the area-navigation NavigationPage label Aug 29, 2024

mattleibow reviewed Sep 2, 2024

View reviewed changes

mattsetaro requested review from jonathanpeppers and mattleibow September 10, 2024 16:03

mattsetaro added 4 commits September 20, 2024 14:37

unsub onappearing event when disappearing

5b2992b

unit test to ensure the event gets unsubscribed properly

596672d

set event to null when cleaning up

d75de3b

also nullify event in the action itself

729d2cf

strong references to prevent garbage collection

71af5b8

github-actions bot force-pushed the navigation-memory-leak branch from cdb7afe to 71af5b8 Compare September 20, 2024 14:37

PureWeen requested changes Sep 20, 2024

View reviewed changes

- store app and window locally so they don't collect

b650607

mattsetaro closed this Oct 23, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Navigation memory leak: Appearing event not being unsubscribed properly #24507

Navigation memory leak: Appearing event not being unsubscribed properly #24507

mattsetaro commented Aug 29, 2024 •

edited by mattleibow

Loading

mattsetaro commented Aug 29, 2024 via email

PureWeen commented Aug 29, 2024

azure-pipelines bot commented Aug 29, 2024

PureWeen commented Aug 29, 2024

azure-pipelines bot commented Aug 29, 2024

jonathanpeppers Aug 29, 2024

mattsetaro Sep 3, 2024

mattleibow left a comment

mattleibow Sep 2, 2024

mattsetaro Sep 3, 2024

mattleibow Sep 2, 2024

mattsetaro commented Sep 3, 2024

mattsetaro commented Sep 10, 2024

mattsetaro commented Sep 10, 2024

mattsetaro commented Sep 19, 2024

PureWeen commented Sep 20, 2024

azure-pipelines bot commented Sep 20, 2024

PureWeen commented Sep 20, 2024

PureWeen Sep 20, 2024

PureWeen commented Sep 20, 2024

PureWeen commented Sep 20, 2024

mattsetaro commented Sep 25, 2024 •

edited

Loading

sitecompass commented Oct 9, 2024

PureWeen commented Oct 10, 2024

		[Fact]
		public void SendDisappearingUnsubscribesAppearingEvent()

		EventHandler _onAppearingEventHandler;
		internal void OnAppearing(Action action)

		@@ -280,6 +280,7 @@ internal bool RemoveLogicalChild(Element element, int index)

		internal bool Owned { get; set; }

		Element _strongParentOverrideReference;

Navigation memory leak: Appearing event not being unsubscribed properly #24507

Navigation memory leak: Appearing event not being unsubscribed properly #24507

Conversation

mattsetaro commented Aug 29, 2024 • edited by mattleibow Loading

Description of Change

Issues Fixed

mattsetaro commented Aug 29, 2024 via email

PureWeen commented Aug 29, 2024

azure-pipelines bot commented Aug 29, 2024

PureWeen commented Aug 29, 2024

azure-pipelines bot commented Aug 29, 2024

jonathanpeppers Aug 29, 2024

Choose a reason for hiding this comment

mattsetaro Sep 3, 2024

Choose a reason for hiding this comment

mattleibow left a comment

Choose a reason for hiding this comment

mattleibow Sep 2, 2024

Choose a reason for hiding this comment

mattsetaro Sep 3, 2024

Choose a reason for hiding this comment

mattleibow Sep 2, 2024

Choose a reason for hiding this comment

mattsetaro commented Sep 3, 2024

mattsetaro commented Sep 10, 2024

mattsetaro commented Sep 10, 2024

mattsetaro commented Sep 19, 2024

PureWeen commented Sep 20, 2024

azure-pipelines bot commented Sep 20, 2024

PureWeen commented Sep 20, 2024

PureWeen Sep 20, 2024

Choose a reason for hiding this comment

PureWeen commented Sep 20, 2024

PureWeen commented Sep 20, 2024

mattsetaro commented Sep 25, 2024 • edited Loading

sitecompass commented Oct 9, 2024

PureWeen commented Oct 10, 2024

mattsetaro commented Aug 29, 2024 •

edited by mattleibow

Loading

mattsetaro commented Sep 25, 2024 •

edited

Loading