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

Fix racy access to _tsfTryRedrawCanvas in TermControl #10549

Merged
3 commits merged into from
Jul 6, 2021

Conversation

lhecker
Copy link
Member

@lhecker lhecker commented Jul 2, 2021

Previously TermControl::Close destroyed all ThrottledFuncs to ensure they're not scheduling any callbacks on the UI thread, as the call to Close signals the point at which the TermControl isn't part of the UI thread anymore. _CursorPositionChanged tried to prevent access to the potentially deallocated _tsfTryRedrawCanvas by checking the std::shared_ptr for nullability, but since the deallocation happens on the UI thread and the nullability check on a background thread, this check introduced a race condition.

This commit solves the issue by not deallocating any ThrottledFuncs anymore and instead checking the _closing flag inside the ThrottledFunc callback on the UI thread.

Additionally this commit cleans up some antipatterns around the use of std::optional.

PR Checklist

Validation Steps Performed

  • Opening and closing tabs doesn't crash ✔️
  • Printing long text doesn't crash ✔️
  • Manual scrolling doesn't crash ✔️
  • ^G / the audible bell doesn't crash ✔️

@ghost ghost added Area-TerminalControl Issues pertaining to the terminal control (input, selection, keybindings, mouse interaction, etc.) Issue-Bug It either shouldn't be doing this or needs an investigation. Priority-1 A description (P1) Product-Terminal The new Windows Terminal. Severity-Crash Crashes are real bad news. labels Jul 2, 2021
@@ -183,6 +183,12 @@ namespace winrt::Microsoft::Terminal::Control::implementation

winrt::Windows::UI::Xaml::Controls::SwapChainPanel::LayoutUpdated_revoker _layoutUpdatedRevoker;

inline bool _IsClosing() const noexcept {
// _closing isn't atomic and may only be accessed from the main thread.
assert(Dispatcher().HasThreadAccess());
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I previously wanted to introduce a cool macro for this in WinRTUtils, but I realized, that global state would only work properly if it's shared using a .dll. A .lib like that wouldn't do that for us. 😟

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This assert is compiled out in debug builds, correct?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, compiled out in release builds./

@DHowett DHowett added zPreview-Service-Queued-1.13 A floating label that tracks the current Preview version for servicing purposes. zStable-Service-Queued-1.12 A floating label that tracks the current Stable version for servicing purposes. labels Jul 2, 2021
@lhecker
Copy link
Member Author

lhecker commented Jul 2, 2021

A branch with a minimalistic set of changes for 1.8 is ready for backporting.

This PR in particular needs to be evaluated very carefully and theoretically as the interaction with _closing is basically a "logical race condition". Despite that I forgot to set the _closing variable to true prior to my latest commit, the code worked fine on my PC through many rounds of testing, which just further proves how much of a race condition this really is.

@DHowett
Copy link
Member

DHowett commented Jul 6, 2021

note: i edited your PR body to make sure the Closes verb was repeated for each closed issue. GitHub will not close two issues if you say Closes X, Y.

@@ -183,6 +183,12 @@ namespace winrt::Microsoft::Terminal::Control::implementation

winrt::Windows::UI::Xaml::Controls::SwapChainPanel::LayoutUpdated_revoker _layoutUpdatedRevoker;

inline bool _IsClosing() const noexcept {
// _closing isn't atomic and may only be accessed from the main thread.
assert(Dispatcher().HasThreadAccess());
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, compiled out in release builds./

@lhecker lhecker added the Needs-Second It's a PR that needs another sign-off label Jul 6, 2021
@lhecker lhecker added the AutoMerge Marked for automatic merge by the bot when requirements are met label Jul 6, 2021
@ghost
Copy link

ghost commented Jul 6, 2021

Hello @lhecker!

Because this pull request has the AutoMerge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (@msftbot) and give me an instruction to get started! Learn more here.

@ghost ghost merged commit 83c6bce into main Jul 6, 2021
@ghost ghost deleted the dev/lhecker/exit-crash-fix branch July 6, 2021 21:59
@DHowett DHowett removed zStable-Service-Queued-1.12 A floating label that tracks the current Stable version for servicing purposes. zPreview-Service-Queued-1.13 A floating label that tracks the current Preview version for servicing purposes. labels Jul 7, 2021
DHowett pushed a commit that referenced this pull request Jul 7, 2021
Previously `TermControl::Close` destroyed all `ThrottledFunc`s to ensure they're not scheduling any callbacks on the UI thread, as the call to `Close` signals the point at which the `TermControl` isn't part of the UI thread anymore. `_CursorPositionChanged` tried to prevent access to the potentially deallocated `_tsfTryRedrawCanvas` by checking the `std::shared_ptr` for nullability, but since the deallocation happens on the UI thread and the nullability check on a background thread, this check introduced a race condition.

This commit solves the issue by not deallocating any `ThrottledFunc`s anymore and instead checking the `_closing` flag inside the `ThrottledFunc` callback on the UI thread.

Additionally this commit cleans up some antipatterns around the use of `std::optional`.

## PR Checklist
* [x] Closes #10479
* [x] Closes #10302

## Validation Steps Performed

* Opening and closing tabs doesn't crash ✔️
* Printing long text doesn't crash ✔️
* Manual scrolling doesn't crash ✔️
* ^G / the audible bell doesn't crash ✔️

(cherry picked from commit 83c6bce)
@ghost
Copy link

ghost commented Jul 14, 2021

🎉Windows Terminal v1.9.1942.0 has been released which incorporates this pull request.:tada:

Handy links:

@ghost
Copy link

ghost commented Jul 14, 2021

🎉Windows Terminal Preview v1.10.1933.0 has been released which incorporates this pull request.:tada:

Handy links:

This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-TerminalControl Issues pertaining to the terminal control (input, selection, keybindings, mouse interaction, etc.) AutoMerge Marked for automatic merge by the bot when requirements are met Issue-Bug It either shouldn't be doing this or needs an investigation. Needs-Second It's a PR that needs another sign-off Priority-1 A description (P1) Product-Terminal The new Windows Terminal. Severity-Crash Crashes are real bad news.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Entire Terminal app is randomly crashing while closing tabs Exiting a tab sometimes closes the entire window
3 participants