-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
BUG: Crash on window resize #2277
Comments
I came here to post this since this immediately happened to me, and is repeatable. Guess I'm not the only one. |
On my system, the crash occurs if the width the terminal window < ~850px, no matter the amount of tabs. This is with 150% display scaling in display options. The height of the window seems to have no impact on stability. |
Terminal people: the error is Perhaps the terminal is adjusting the size of something in response to some size-changed event, and we get into a state where we're oscillating or something like that. |
Not sure if I will be able to do a build myself to test. We haven't officially rolled out 1903 internally, so I had upgrade my laptop and dev VM, and of course Terminal is working out of the box on the dev VM, but other software is not working with 1903 so IT is on track to destroy and redploy the VM with 1803. So while I may be able to get the dev tools setup and build from master on the VM before they do that, it wouldn't really serve to validate the fix since Terminal works there.
Consistently crashes on launch, draws a window frame but I never see the terminal application actually load inside it, and the window just goes away after a few seconds. I just tried playing with setting {
"$schema": "https://aka.ms/terminal-profiles-schema",
"defaultProfile": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}",
"profiles":
[
{
"guid": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}",
"name": "Windows PowerShell",
"commandline": "powershell.exe",
"hidden": false,
"tabTitle": "PWSH"
},
{
"guid": "{0caa0dad-35be-5f56-a8ff-afceeeaa6101}",
"name": "cmd",
"commandline": "cmd.exe",
"hidden": false,
"tabTitle": "CMD"
},
{
"guid": "{574e775e-4f2a-5b96-ac1e-a2962a402336}",
"hidden": false,
"name": "PowerShell Core",
"source": "Windows.Terminal.PowershellCore",
"tabTitle": "PWSH Core"
},
{
"guid": "{2c4de342-38b7-51cf-b940-2309a097f518}",
"hidden": false,
"name": "Ubuntu",
"source": "Windows.Terminal.Wsl",
"tabTitle": "WSL"
},
{
"guid": "{b453ae62-4e3d-5e58-b989-0a998ec441b8}",
"hidden": true,
"name": "Azure Cloud Shell",
"source": "Windows.Terminal.Azure",
"tabTitle": "AZSH"
}
],
"schemes": [],
"keybindings": []
} I also noticed above this error is also reported for font sizes smaller than 10 so I tried adding |
Hey everyone, just an update here: I've dug real deep into XAML over the last week, and working with @teaP, we were able to find that the source of the At the time of writing it's unclear when we'll ingest that update and push an update to the store. We'll keep you posted in this thread when we know more. Thanks all for help with getting repro steps found! |
For me the crash on launch has been resolved in the released 0.7.3291.0 build. 😄 |
True, it doesn't crash when I move between windows now, but if I then maximize it, it immediately crashes. As before, if I open a second tab before maximizing, it does not crash. Not yet resolved, but getting better. |
## Summary of the Pull Request Updates MUX to the latest pre-release version. This prerelease has a fix for a certain `E_LAYOUTCYCLE` bug in the TabView that was causing an untold number of crashes for us. Thanks again @teaP! ## PR Checklist * [x] Closes #3303 * [x] Closes #2277 * [x] I work here * [n/a] Tests added/passed * [n/a] Requires documentation to be updated
Updates MUX to the latest pre-release version. This prerelease has a fix for a certain `E_LAYOUTCYCLE` bug in the TabView that was causing an untold number of crashes for us. Thanks again @teaP! * [x] Closes #3303 * [x] Closes #2277 * [x] I work here * [n/a] Tests added/passed * [n/a] Requires documentation to be updated (cherry picked from commit 2f0abc2)
🎉This issue was addressed in #3832, which has now been successfully released as Handy links: |
When user resizes window, snap the size to align with the character grid (like e.g. putty, mintty and most unix terminals). Properly resolves arbitrary pane configuration (even with different font sizes and padding) trying to align each pane as close as possible. It also fixes terminal minimum size enforcement which was not quite well handled, especially with multiple panes. This PR does not however try to keep the terminals aligned at other user actions (e.g. font change or pane split). That is to be tracked by some other activity. Snapping is resolved in the pane tree, recursively, so it (hopefully) works for any possible layout. Along the way I had to clean up some things as so to make the resulting code not so cumbersome: 1. Pane.cpp: Replaced _firstPercent and _secondPercent with single _desiredSplitPosition to reduce invariants - these had to be kept in sync so their sum always gives 1 (and were not really a percent). The desired part refers to fact that since panes are aligned, there is usually some deviation from that ratio. 2. Pane.cpp: Fixed _GetMinSize() - it was improperly accounting for split direction 3. TerminalControl: Made dedicated member for padding instead of reading it from a control itself. This is because the winrt property functions turned out to be slow and this algorithm needs to access it many times. I also cached scrollbar width for the same reason. 4. AppHost: Moved window to client size resolution to virtual method, where IslandWindow and NonClientIslandWindow have their own implementations (as opposite to pointer casting). One problem with current implementation is I had to make a long call chain from the window that requests snapping to the (root) pane that implements it: IslandWindow -> AppHost's callback -> App -> TerminalPage -> Tab -> Pane. I don't know if this can be done better. ## Validation Steps Performed Spam split pane buttons, randomly change font sizes with ctrl+mouse wheel and drag the window back and forth. Closes #2834 Closes #2277
🎉This issue was addressed in #3181, which has now been successfully released as Handy links: |
This keeps happening without failure when I am :
VersionWindows Terminal 1.0.1811.0 Screenshot |
@fevernova90 That looks like a new crash to me - would you mind filing a new issue for it? I don't want to muddle up this existing thread with a new crash who's source might be unrelated to the original. Thanks! |
@zadjii-msft I have figured out the cause of the my Windows Terminal crashing with multiple tabs after seeing the event logs. There's one app that hooked up into Windows Terminal, it is RivaTuner Statistics Server (which comes bundled when you installed MSI Afterburner). I guess this issue is not relevant to everyone who does not tinkering with their GPU using MSI Afterburner. Pasting my log here for info
|
Ah, that makes sense. We've seen a few crashes like that with people using RivaTuner before. Thanks for following up! |
my terminal is not opening at all, and the faulting module is |
@sina-salahshour that is totally unrelated to this thread. There are other, more recent discussions on the topic - go install the media feature pack as a workaround |
Environment
Steps to reproduce
Start terminal. Resize. I pretty consistently get a crash when I get to about the point of the single tab going to zero width.
Start terminal. Add multiple tabs. Resize. I get crashes when the third tab starts to slide under the new tab UI.
Sometimes you can shrink all the way down and back. Sometimes you can shrink all the way down, and it'll crash as it is being expanded.
Expected behavior
Window resizes without crash
Actual behavior
Here's one of the entries from my event log.
Here's the feedback hub entry, which should have dx attached to it:
https://aka.ms/AA5roli
The text was updated successfully, but these errors were encountered: