-
Notifications
You must be signed in to change notification settings - Fork 8.4k
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 a crash in _WritePseudoWindowCallback
#13777
Conversation
Fixes MSFT:40853556 There's a small race here. The renderer thread in ConPTY might notice the terminal is gone, call CloseOutput, and release the vt renderer, and then the window proc fires and decides to minimize/restore the window, triggering an A/V. I'm 100% confident that this has NEVER happened to a real user. But the test labs hit it so much that it makes up ~26% of our crashes.
_WritePseudoWindowCallback
_WritePseudoWindowCallback
Could this also be MSFT:40913882? |
_WritePseudoWindowCallback
_WritePseudoWindowCallback
LOL, thanks for fixing my fixe. I did the same thing to a contributor's PR this exact same week. |
Nah, I'll reply with investigation in that bug. |
// SetPseudoWindowCallback(nullptr), so that we don't just move | ||
// the A/V race to in between checking | ||
// _pseudoWindowMessageCallback and actually calling it. | ||
std::lock_guard<std::mutex> lk(_shutdownLock); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FYI Since C++17 you don't need to specify template parameters anymore - they'll be automatically inferred.
Just from reading the diff, I don't quite get why we wouldn't have to add these guards everywhere else. What makes |
Presumably, this is the only bit of code that can be called from another thread in an unsafe way here. Typically everything else we were doing was always during startup or immediately on shutdown, but now we've got this pesky user32 input thread to deal with window messages that can get in here too now |
That explanation makes sense to me! |
Hello @DHowett! Because this pull request has the Do note that I've been instructed to only help merge pull requests of this repository that have been opened for at least 8 hours, a condition that will be fulfilled in about 2 hours 24 minutes. No worries though, I will be back when the time is right! 😉 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 merge this in 5 minutes |
Hello @DHowett! Because you've given me some instructions on how to help merge this pull request, I'll be modifying my merge approach. Here's how I understand your requirements for merging this pull request:
If this doesn't seem right to you, you can tell me to cancel these instructions and use the auto-merge policy that has been configured for this repository. Try telling me "forget everything I just told you". |
Fixes MSFT:40853556 There's a small race here. The renderer thread in ConPTY might notice the terminal is gone, call CloseOutput, and release the vt renderer, and then the window proc fires and decides to minimize/restore the window, triggering an A/V. I'm 100% confident that this has NEVER happened to a real user. But the test labs hit it so much that it makes up ~26% of our crashes. I haven't tested this cause again, _it doesn't hit in the wild_ (cherry picked from commit f58240c) Service-Card-Id: 85103518 Service-Version: 1.15
🎉 Handy links: |
🎉 Handy links: |
Fixes MSFT:40853556
There's a small race here. The renderer thread in ConPTY might notice the terminal is gone, call CloseOutput, and release the vt renderer, and then the window proc fires and decides to minimize/restore the window, triggering an A/V.
I'm 100% confident that this has NEVER happened to a real user. But the test labs hit it so much that it makes up ~26% of our crashes.
I haven't tested this cause again, it doesn't hit in the wild