Intentionally leak our Application, so that we DON'T crash on exit#5629
Merged
zadjii-msft merged 1 commit intomasterfrom Apr 30, 2020
Merged
Intentionally leak our Application, so that we DON'T crash on exit#5629zadjii-msft merged 1 commit intomasterfrom
zadjii-msft merged 1 commit intomasterfrom
Conversation
DHowett-MSFT
approved these changes
Apr 28, 2020
DHowett-MSFT
approved these changes
Apr 29, 2020
Member
Author
|
@DHowett-MSFT should we selfhost this first as a sanity check? this seems like it can't be right, but hey, it works on my machine |
Contributor
|
Sure, I'll spin a selfghost build. |
Contributor
|
It doesn't seem to be causing issues on Release for me. |
Member
Author
Good enough for me ¯\_(ツ)_/¯ |
zadjii-msft
added
Needs-Second
ghost
requested review from
carlos-zamora
approved these changes
Apr 30, 2020
miniksa
approved these changes
Apr 30, 2020
|
🎉 Handy links: |
9 tasks
This was referenced May 24, 2023
DHowett
pushed a commit
that referenced
this pull request
May 26, 2023
…5451) This is a resurrection of #5629. As it so happens, this crash-on-exit was _not_ specific to my laptop. It's a bug in the XAML platform somewhere, only on Windows 10. In #14843, we moved this leak into `becomeMonarch`. Turns out, we don't just need this leak for the monarch process, but for all of them. It's not a real "leak", because ultimately, our `App` lives for the entire lifetime of our process, and then gets cleaned up when we do. But `dtor`ing the `App` - that's apparently a no-no. Was originally in #15424, but I'm pulling it out for a super-hotfix release. Closes #15410 MSFT:35761869 looks like it was closed as no repro many moons ago. This should close out our hits there (firmly **40% of the crashes we've gotten on 1.18**)
DHowett
pushed a commit
that referenced
this pull request
May 26, 2023
…5451) This is a resurrection of #5629. As it so happens, this crash-on-exit was _not_ specific to my laptop. It's a bug in the XAML platform somewhere, only on Windows 10. In #14843, we moved this leak into `becomeMonarch`. Turns out, we don't just need this leak for the monarch process, but for all of them. It's not a real "leak", because ultimately, our `App` lives for the entire lifetime of our process, and then gets cleaned up when we do. But `dtor`ing the `App` - that's apparently a no-no. Was originally in #15424, but I'm pulling it out for a super-hotfix release. Closes #15410 MSFT:35761869 looks like it was closed as no repro many moons ago. This should close out our hits there (firmly **40% of the crashes we've gotten on 1.18**) (cherry picked from commit aa8ed8c) Service-Card-Id: 89332890 Service-Version: 1.18
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
We've got a weird crash that happens terribly inconsistently, but pretty
readily on migrie's laptop, only in Debug mode. Apparently, there's some
weird ref-counting magic that goes on during teardown, and our
Application doesn't get closed quite right, which can cause us to crash
into the debugger. This of course, only happens on exit, and happens
somewhere in the
...XamlHost.dllcode.Crazily, if we manually leak the
Applicationhere, then the crashdoesn't happen. This doesn't matter, because we really want the
Application to live for the entire lifetime of the process, so the only
time when this object would actually need to get cleaned up is during
exit. So we can safely leak this
Applicationobject, and have it justget cleaned up normally when our process exits.