Fix crash in terminal when tab closed while data is being output #8982
Conversation
This file contains 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
ghost
added
Issue-Bug
carlos-zamora
approved these changes
Feb 1, 2021
carlos-zamora
added
zPreview-Service-Queued-1.13
zadjii-msft
approved these changes
Feb 1, 2021
Co-authored-by: Mike Griese <migrie@microsoft.com>
DHowett
approved these changes
Feb 1, 2021
DHowett
added
the
AutoMerge
|
Hello @DHowett! Because this pull request has the 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 (
|
ghost
merged commit 
|
(Thank you, as always!) |
DHowett
removed
zStable-Service-Queued-1.12
DHowett
pushed a commit
that referenced
this pull request
Feb 5, 2021
If there is data being output when a tab is closed, that can sometimes result in the application crashing, because the renderer may still be in use at the time is it destroyed. This PR attempts to prevent that from happening by adding a lock in the `TermControl::Close` method. What we're trying to prevent is the connection thread still being active, and potentially accessing the renderer, after it has been destroyed. So by acquiring the terminal lock in `TermControl::Close`, after we've stopped accepting new output, we can be sure that the connection thread is no longer active (it holds the lock while it is processing output). So once we've acquired and released the lock, it should be safe to tear down and destroy the renderer. ## Validation Steps Performed While this crash is difficult to reproduce in general usage, it occurred quite frequently when testing my `DECPS` implementation (there is some tricky thread synchronisation, which seems more likely to trigger the issue). With this patch applied, though, those crashes have stopped occurring. I've also stepped through the shutdown code in the debugger, manually freezing threads to get them aligned in the right way to trigger the crash (as explained in issue #8734). Again with the patch applied, I can no longer get the crash to occur. Closes #8734 (cherry picked from commit 40ebe5a)
DHowett
pushed a commit
that referenced
this pull request
Feb 5, 2021
If there is data being output when a tab is closed, that can sometimes result in the application crashing, because the renderer may still be in use at the time is it destroyed. This PR attempts to prevent that from happening by adding a lock in the `TermControl::Close` method. What we're trying to prevent is the connection thread still being active, and potentially accessing the renderer, after it has been destroyed. So by acquiring the terminal lock in `TermControl::Close`, after we've stopped accepting new output, we can be sure that the connection thread is no longer active (it holds the lock while it is processing output). So once we've acquired and released the lock, it should be safe to tear down and destroy the renderer. ## Validation Steps Performed While this crash is difficult to reproduce in general usage, it occurred quite frequently when testing my `DECPS` implementation (there is some tricky thread synchronisation, which seems more likely to trigger the issue). With this patch applied, though, those crashes have stopped occurring. I've also stepped through the shutdown code in the debugger, manually freezing threads to get them aligned in the right way to trigger the crash (as explained in issue #8734). Again with the patch applied, I can no longer get the crash to occur. Closes #8734 (cherry picked from commit 40ebe5a)
|
🎉 Handy links: |
ghost
mentioned this pull request
|
🎉 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
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.
If there is data being output when a tab is closed, that can sometimes
result in the application crashing, because the renderer may still be in
use at the time is it destroyed. This PR attempts to prevent that from
happening by adding a lock in the
TermControl::Closemethod.What we're trying to prevent is the connection thread still being
active, and potentially accessing the renderer, after it has been
destroyed. So by acquiring the terminal lock in
TermControl::Close,after we've stopped accepting new output, we can be sure that the
connection thread is no longer active (it holds the lock while it is
processing output). So once we've acquired and released the lock, it
should be safe to tear down and destroy the renderer.
Validation Steps Performed
While this crash is difficult to reproduce in general usage, it occurred
quite frequently when testing my
DECPSimplementation (there is sometricky thread synchronisation, which seems more likely to trigger the
issue). With this patch applied, though, those crashes have stopped
occurring.
I've also stepped through the shutdown code in the debugger, manually
freezing threads to get them aligned in the right way to trigger the
crash (as explained in issue #8734). Again with the patch applied, I can
no longer get the crash to occur.
Closes #8734