Snapping to smaller screen with a COOKED_READ crashes conpty #1856
Comments
ghost
added
Needs-Triage
carlos-zamora
added
Issue-Bug
carlos-zamora
changed the title
|
This seems like it's related to #1572, but since you're on 0.2.1831.0 (which includes the fix for that issue), it can't be the same root cause as that issue. |
zadjii-msft
added
the
Area-UserInterface
|
This may be the same as #1795. We'll leave it open just to make sure. |
DHowett-MSFT
removed
the
Needs-Triage
|
Largely, this issue's been fixed, but there's certainly another bug here, and it goes beyond the terminal. If you create a conpty, and then you have a COOKED_READ with some input in that conpty, then snap the Terminal window to a smaller size like this, the conpty crashes. The conpty crashes when resizing, specifically due to the presence of the input line. I thought I had a fix in d34a3be for this, but I'm not sure that it totally works. It seems trivial enough, but knowing what I know about COOKED_READs, an easy fix is usually wrong. There's almost certainly edge cases it misses. I want to leave this bug open to track that specific crash. |
zadjii-msft
added
Area-Interaction
zadjii-msft
changed the title
|
With v 6.0 is even worse. This is the error logged in the event viewer: Faulting application name: WindowsTerminal.exe, version: 1.0.1910.22001, time stamp: 0x5daf7ab2 |
|
Pulling this into 1.0 since we think it might actually be a pretty common crash |
… window (#5620) Hide any commandline (cooked read) we have before we begin a resize, and show it again after the resize. ## References * I found #5618 while I was working on this. ## PR Checklist * [x] Closes #1856 * [x] I work here * [x] Tests added/passed * [n/a] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments Basically, during a resize, we try to restore the viewport position correctly, and part of that checks where the current commandline ends. However, when we do that, the commandline's _current_ state still reflects the _old_ buffer size, so resizing to be smaller can cause us to throw an exception, when we find that the commandline doesn't fit in the new viewport cleanly. By hiding it, then redrawing it, we avoid this problem entirely. We don't need to perform the check on the old commandline contents (since they'll be empty), and we'll redraw it just fine for the new buffer size ## Validation Steps Performed * ran tests * checked resizing, snapping in conhost with a cooked read * checked resizing, snapping in the Terminal with a cooked read
ghost
added
Resolution-Fix-Committed
|
🎉This issue was addressed in #5620, which has now been successfully released as Handy links: |
Environment
Steps to reproduce
full screen the terminal window and use the keys "windows + shift + arrow" to move the window to your second screen
Expected behavior
Go full screen on second monitor
Actual behavior
When I move it from a 1920x1080 screen to a 2560x1080 screen it goes full screen. When moving it from a 2560x1080 screen to a 1920x1080 screen the terminal crashes.
Message event viewer (Dutch)
Naam van toepassing met fout: WindowsTerminal.exe, versie: 1.0.1907.2001, tijdstempel: 0x5d1bd2d0
Naam van module met fout: ucrtbase.dll, versie: 10.0.18362.1, tijdstempel: 0x5cbddb81
Uitzonderingscode: 0xc0000409
Foutmarge: 0x000000000006d3be
Id van proces met fout: 0x3028
Starttijd van toepassing met fout: 0x01d534b9425f56b0
Pad naar toepassing met fout: C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_0.2.1831.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe
Pad naar module met fout: C:\WINDOWS\System32\ucrtbase.dll
Rapport-id: d822f0b0-3805-4c9f-b74e-87c80dc48334
Volledige pakketnaam met fout: Microsoft.WindowsTerminal_0.2.1831.0_x64__8wekyb3d8bbwe
Relatieve toepassings-id van pakket met fout: App
The text was updated successfully, but these errors were encountered: