Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Theoretical fix for some crashes #16047

Merged
merged 3 commits into from
Sep 28, 2023
Merged

Conversation

zadjii-msft
Copy link
Member

Found this while looking through dumps for failure f544cf8e-1879-c59b-3f0b-1a364b92b974. That's MSFT:45210947. (1% of our 1.19 crashes)

From the dump I looked at,

Looks like,

  • we're on Windows 10
  • We're refrigerating a window
  • We are pumping the remaining XAML messages as we refrigerate (_pumpRemainingXamlMessages)
  • In there, we're finally getting the TerminalPage::_CompleteInitialization
  • that calls up to the _root->Initialized lambda set up in TerminalWindow::Initialize
  • There it tries to get the launch mode from the settings, and explodes. Presumably _settings is null, but can't see in this dump.

so the window is closing before it's initialized.

When we _warmWindow = std::move(_host->Refrigerate()), we call AppHost::Refrigerate, which will null out the TerminalWindow. So when we're getting to TerminalWindow::Initialize, we're calling that on a nullptr. That's the trick.

We need to revoke the internal Initialized callback. Which makes sense. It's a lambda that binds this 🤦


After more looking, it really doesn't seem like the stacks that are tracked in f544cf8e-1879-c59b-3f0b-1a364b92b974 look like the same stack that I was debugging, but this is a realy issue regardless.

Found this while looking through dumps for failure
`f544cf8e-1879-c59b-3f0b-1a364b92b974`. That's MSFT:45210947.

From the dump I looked at,

Looks like,

* we're on Windows 10
* We're refrigerating a window
* We are pumping the remaining XAML messages as we refrigerate
  (`_pumpRemainingXamlMessages`)
* In there, we're finally getting the `TerminalPage::_CompleteInitialization`
* that calls up to the `_root->Initialized` lambda set up in
  `TerminalWindow::Initialize`
* There it tries to get the launch mode from the settings, and explodes.
  Presumably _settings is null, but can't see in this dump.

so the window is closing before it's initialized.

When we `_warmWindow = std::move(_host->Refrigerate())`, we call
`AppHost::Refrigerate`, which will null out the TerminalWindow. So when we're
getting to `TerminalWindow::Initialize`, we're calling that on a nullptr. That's
the trick.

We need to revoke the internal Initialized callback. Which makes sense. It's a
lambda that binds _this_ 🤦

---

After more looking, it really doesn't _seem_ like the stacks that are tracked in `f544cf8e-1879-c59b-3f0b-1a364b92b974` look like the same stack that I was debugging, but this _is_ a realy issue regardless.
@zadjii-msft
Copy link
Member Author

note: I'm not sure I could repro this locally. This is more of a "well, look at the code, that's definitely a bug" fix.

@zadjii-msft zadjii-msft merged commit 7073ec0 into main Sep 28, 2023
17 checks passed
@zadjii-msft zadjii-msft deleted the dev/migrie/b/msft-45210947-maybe branch September 28, 2023 18:21
DHowett pushed a commit that referenced this pull request Sep 29, 2023
Found this while looking through dumps for failure
`f544cf8e-1879-c59b-3f0b-1a364b92b974`. That's MSFT:45210947. (1% of our
1.19 crashes)

From the dump I looked at,

Looks like,

* we're on Windows 10
* We're refrigerating a window
* We are pumping the remaining XAML messages as we refrigerate
(`_pumpRemainingXamlMessages`)
* In there, we're finally getting the
`TerminalPage::_CompleteInitialization`
* that calls up to the `_root->Initialized` lambda set up in
`TerminalWindow::Initialize`
* There it tries to get the launch mode from the settings, and explodes.
Presumably _settings is null, but can't see in this dump.

so the window is closing before it's initialized.

When we `_warmWindow = std::move(_host->Refrigerate())`, we call
`AppHost::Refrigerate`, which will null out the TerminalWindow. So when
we're getting to `TerminalWindow::Initialize`, we're calling that on a
nullptr. That's the trick.

We need to revoke the internal Initialized callback. Which makes sense.
It's a lambda that binds _this_ 🤦

---

After more looking, it really doesn't _seem_ like the stacks that are
tracked in `f544cf8e-1879-c59b-3f0b-1a364b92b974` look like the same
stack that I was debugging, but this _is_ a realy issue regardless.

(cherry picked from commit 7073ec0)
Service-Card-Id: 90672654
Service-Version: 1.19
DHowett pushed a commit that referenced this pull request Nov 7, 2023
Found this while looking through dumps for failure
`f544cf8e-1879-c59b-3f0b-1a364b92b974`. That's MSFT:45210947. (1% of our
1.19 crashes)

From the dump I looked at,

Looks like,

* we're on Windows 10
* We're refrigerating a window
* We are pumping the remaining XAML messages as we refrigerate
(`_pumpRemainingXamlMessages`)
* In there, we're finally getting the
`TerminalPage::_CompleteInitialization`
* that calls up to the `_root->Initialized` lambda set up in
`TerminalWindow::Initialize`
* There it tries to get the launch mode from the settings, and explodes.
Presumably _settings is null, but can't see in this dump.

so the window is closing before it's initialized.

When we `_warmWindow = std::move(_host->Refrigerate())`, we call
`AppHost::Refrigerate`, which will null out the TerminalWindow. So when
we're getting to `TerminalWindow::Initialize`, we're calling that on a
nullptr. That's the trick.

We need to revoke the internal Initialized callback. Which makes sense.
It's a lambda that binds _this_ 🤦

Service-Card-Id: 90878965
Service-Version: 1.18

---

After more looking, it really doesn't _seem_ like the stacks that are
tracked in `f544cf8e-1879-c59b-3f0b-1a364b92b974` look like the same
stack that I was debugging, but this _is_ a realy issue regardless.

(cherry picked from commit 7073ec0)
DHowett pushed a commit that referenced this pull request Nov 7, 2023
Found this while looking through dumps for failure
`f544cf8e-1879-c59b-3f0b-1a364b92b974`. That's MSFT:45210947. (1% of our
1.19 crashes)

From the dump I looked at,

Looks like,

* we're on Windows 10
* We're refrigerating a window
* We are pumping the remaining XAML messages as we refrigerate
(`_pumpRemainingXamlMessages`)
* In there, we're finally getting the
`TerminalPage::_CompleteInitialization`
* that calls up to the `_root->Initialized` lambda set up in
`TerminalWindow::Initialize`
* There it tries to get the launch mode from the settings, and explodes.
Presumably _settings is null, but can't see in this dump.

so the window is closing before it's initialized.

When we `_warmWindow = std::move(_host->Refrigerate())`, we call
`AppHost::Refrigerate`, which will null out the TerminalWindow. So when
we're getting to `TerminalWindow::Initialize`, we're calling that on a
nullptr. That's the trick.

We need to revoke the internal Initialized callback. Which makes sense.
It's a lambda that binds _this_ 🤦

Service-Card-Id: 90878965
Service-Version: 1.18

---

After more looking, it really doesn't _seem_ like the stacks that are
tracked in `f544cf8e-1879-c59b-3f0b-1a364b92b974` look like the same
stack that I was debugging, but this _is_ a realy issue regardless.

(cherry picked from commit 7073ec0)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Development

Successfully merging this pull request may close these issues.

4 participants