Use `weak_ptr`s for `AppHost` for coroutines #16065

zadjii-msft · 2023-09-29T18:44:26Z

See MSFT:46763065. Looks like we're in the middle of being Refrigerated, we're pumping messages, and as we pump messages, we get to a co_await in AppHost::_WindowInitializedHandler. When we resume, we just try to use this like everything's fine but OH NO, IT'S NOT.

To fix this, I'm

Adding enable_shared_from_this to AppHost
Holding the AppHost in a shared_ptr in WindowThread
- though, this is a singular owning shared_ptr. This is probably ripe for other footguns, but there's little we can do about this.
whenever we co_await in AppHost, make sure we grab a weak ref first, and check it on the other side.

This is another "squint and yep that's a bug" fix, that I haven't been able to verify locally. This is
allegedly about 10% of our 1.19 crashes after 3 days.

Closes #16061

See MSFT:46763065. Looks like we're in the middle of being `Refrigerate`d, we're pumping messages, and as we pump messages, we get to a `co_await` in `AppHost::_WindowInitializedHandler`. When we resume, we just try to use `this` like everything's fine but OH NO, IT'S NOT. To fix this, I'm * Adding `enable_shared_from_this` to `AppHost` * Holding the `AppHost` in a shared_ptr in WindowThread - though, this is a singular owning `shared_ptr`. This is probably ripe for other footguns, but there's little we can do about this. * whenever we `co_await` in `AppHost`, make sure we grab a weak ref first, and check it on the other side. This is another "squint and yep that's a bug" fix, that I haven't been able to verify locally. This is [allegedly](https://media.tenor.com/VQi3bktwLdIAAAAC/allegedly-supposedly.gif) about 10% of our 1.19 crashes after 3 days. Closes #16061

lhecker · 2023-09-29T19:43:07Z

src/cascadia/WindowsTerminal/AppHost.cpp

@@ -931,8 +931,17 @@ winrt::fire_and_forget AppHost::_peasantNotifyActivateWindow()
    const auto peasant = _peasant;
    const auto hwnd = _window->GetHandle();

+    auto weakThis{ weak_from_this() };
+
    co_await winrt::resume_background();


Does this need to run on the BG thread in the first place?

I had it on a background thread so that a hung Monarch wouldn't hang a peasant process when the peasant gets activated.

I suppose these days, it's all the same process, so we could pull this one.

See MSFT:46763065. Looks like we're in the middle of being `Refrigerate`d, we're pumping messages, and as we pump messages, we get to a `co_await` in `AppHost::_WindowInitializedHandler`. When we resume, we just try to use `this` like everything's fine but OH NO, IT'S NOT. To fix this, I'm * Adding `enable_shared_from_this` to `AppHost` * Holding the `AppHost` in a shared_ptr in WindowThread - though, this is a singular owning `shared_ptr`. This is probably ripe for other footguns, but there's little we can do about this. * whenever we `co_await` in `AppHost`, make sure we grab a weak ref first, and check it on the other side. This is another "squint and yep that's a bug" fix, that I haven't been able to verify locally. This is [allegedly](https://media.tenor.com/VQi3bktwLdIAAAAC/allegedly-supposedly.gif) about 10% of our 1.19 crashes after 3 days. Closes #16061 (cherry picked from commit 8521aae) Service-Card-Id: 90731961 Service-Version: 1.18

See MSFT:46763065. Looks like we're in the middle of being `Refrigerate`d, we're pumping messages, and as we pump messages, we get to a `co_await` in `AppHost::_WindowInitializedHandler`. When we resume, we just try to use `this` like everything's fine but OH NO, IT'S NOT. To fix this, I'm * Adding `enable_shared_from_this` to `AppHost` * Holding the `AppHost` in a shared_ptr in WindowThread - though, this is a singular owning `shared_ptr`. This is probably ripe for other footguns, but there's little we can do about this. * whenever we `co_await` in `AppHost`, make sure we grab a weak ref first, and check it on the other side. This is another "squint and yep that's a bug" fix, that I haven't been able to verify locally. This is [allegedly](https://media.tenor.com/VQi3bktwLdIAAAAC/allegedly-supposedly.gif) about 10% of our 1.19 crashes after 3 days. Closes #16061 (cherry picked from commit 8521aae) Service-Card-Id: 90731962 Service-Version: 1.19

For history: > This is MSFT:46763065 internally. Dumps show this repros on 1.19 too. > > This was previously #16061 which had a theoretical fix in #16065. Looks like you're on Terminal Stable v1.18.2822.0, and https://github.com/microsoft/terminal/releases/tag/v1.18.2822.0 is supposed to have had that fix in it. Dang. > well this is embarrassing ... I never actually checked if we _still had a `_window`_. We're alive, yay! But we're still in the middle of refrigerating. So, there's no HWND anymore Attempt to fix this by actually ensuring there's a `_window` in `AppHost::_WindowInitializedHandler` Closes #16235

For history: > This is MSFT:46763065 internally. Dumps show this repros on 1.19 too. > > This was previously #16061 which had a theoretical fix in #16065. Looks like you're on Terminal Stable v1.18.2822.0, and https://github.com/microsoft/terminal/releases/tag/v1.18.2822.0 is supposed to have had that fix in it. Dang. > well this is embarrassing ... I never actually checked if we _still had a `_window`_. We're alive, yay! But we're still in the middle of refrigerating. So, there's no HWND anymore Attempt to fix this by actually ensuring there's a `_window` in `AppHost::_WindowInitializedHandler` Closes #16235 (cherry picked from commit 59dcbbe) Service-Card-Id: 91041358 Service-Version: 1.18

For history: > This is MSFT:46763065 internally. Dumps show this repros on 1.19 too. > > This was previously #16061 which had a theoretical fix in #16065. Looks like you're on Terminal Stable v1.18.2822.0, and https://github.com/microsoft/terminal/releases/tag/v1.18.2822.0 is supposed to have had that fix in it. Dang. > well this is embarrassing ... I never actually checked if we _still had a `_window`_. We're alive, yay! But we're still in the middle of refrigerating. So, there's no HWND anymore Attempt to fix this by actually ensuring there's a `_window` in `AppHost::_WindowInitializedHandler` Closes #16235 (cherry picked from commit 59dcbbe) Service-Card-Id: 91041359 Service-Version: 1.19

For history: > This is MSFT:46763065 internally. Dumps show this repros on 1.19 too. > > This was previously #16061 which had a theoretical fix in #16065. Looks like you're on Terminal Stable v1.18.2822.0, and https://github.com/microsoft/terminal/releases/tag/v1.18.2822.0 is supposed to have had that fix in it. Dang. > well this is embarrassing ... I never actually checked if we _still had a `_window`_. We're alive, yay! But we're still in the middle of refrigerating. So, there's no HWND anymore Attempt to fix this by actually ensuring there's a `_window` in `AppHost::_WindowInitializedHandler` Closes #16235 (cherry picked from commit 59dcbbe) Service-Card-Id: 91041358 Service-Version: 1.18

For history: > This is MSFT:46763065 internally. Dumps show this repros on 1.19 too. > > This was previously microsoft#16061 which had a theoretical fix in microsoft#16065. Looks like you're on Terminal Stable v1.18.2822.0, and https://github.com/microsoft/terminal/releases/tag/v1.18.2822.0 is supposed to have had that fix in it. Dang. > well this is embarrassing ... I never actually checked if we _still had a `_window`_. We're alive, yay! But we're still in the middle of refrigerating. So, there's no HWND anymore Attempt to fix this by actually ensuring there's a `_window` in `AppHost::_WindowInitializedHandler` Closes microsoft#16235

microsoft-github-policy-service bot added Issue-Bug It either shouldn't be doing this or needs an investigation. Area-Windowing Window frame, quake mode, tearout Product-Terminal The new Windows Terminal. labels Sep 29, 2023

lhecker approved these changes Sep 29, 2023

View reviewed changes

carlos-zamora approved these changes Oct 2, 2023

View reviewed changes

DHowett approved these changes Oct 3, 2023

View reviewed changes

DHowett merged commit 8521aae into main Oct 3, 2023
17 checks passed

DHowett deleted the dev/migrie/b/16061-another-psychic-fix branch October 3, 2023 20:31

zadjii-msft mentioned this pull request Oct 27, 2023

WindowsTerminal!AppHost::_WindowInitializedHandler$_ResumeCoro$1+0x2cc -- access violation at Windows startup post Windows update restart #16235

Closed

zadjii-msft mentioned this pull request Nov 6, 2023

Another theoretical fix for a crash #16267

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Use `weak_ptr`s for `AppHost` for coroutines #16065

Use `weak_ptr`s for `AppHost` for coroutines #16065

zadjii-msft commented Sep 29, 2023

lhecker Sep 29, 2023

zadjii-msft Oct 2, 2023

Use weak_ptrs for AppHost for coroutines #16065

Use weak_ptrs for AppHost for coroutines #16065

Conversation

zadjii-msft commented Sep 29, 2023

lhecker Sep 29, 2023

Choose a reason for hiding this comment

zadjii-msft Oct 2, 2023

Choose a reason for hiding this comment

Use `weak_ptr`s for `AppHost` for coroutines #16065

Use `weak_ptr`s for `AppHost` for coroutines #16065