starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-03 21:25:34 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Windows Terminal hangs when erasing scrollback #3036

New Issue
Closed
opened 2026-01-30 23:11:24 +00:00 by claunia · 4 comments
claunia commented 2026-01-30 23:11:24 +00:00
Owner
Copy Link

Originally created by @j4james on GitHub (Jul 31, 2019).

Originally assigned to: @PankajBhojwani on GitHub.

Environment

Windows build number: Version 10.0.18362.175
Windows Terminal version (if applicable): Commit a08666b58e

Steps to reproduce

  1. Start the Windows Terminal (Dev Build).
  2. Open an Ubuntu tab (or whatever Linux shell you have).
  3. Do a bunch of directory listings that really fill up the scrollback buffer (the System32 directory is good for that).
  4. Execute printf "\e[3J" to clear the scrollback buffer.

Expected behavior

The scrollback buffer should be cleared and control returned to the user almost immediately.

Actual behavior

The app essentially stops responding. It will return to normal eventually, but how long that takes depends on the speed of your computer and how full the scrollback was to start with.

This might be a duplicate of one of the other freeze-on-exit bugs (e.g. #1445), since the terminal seems to generate an erase scrollback call whenever you exit. But it only happens when actually typing exit in the shell - closing the tab directly works OK.

From what I've been able to determine, the source of the problem is in the Terminal::EraseInDisplay method. When the eraseType is EraseType::Scrollback, it performs a loop to clear every line of the scrollback:

a08666b58e/src/cascadia/TerminalCore/TerminalApi.cpp (L340-L345)

Note that the eraseIter OutputCellIterator is set to the size of the full area being cleared, but a _buffer->Write call is made with that iterator for every line. Each one of those calls is enough to clear the entire area, so it's essentially performing a huge write operation over and over again. If your scrollback buffer is large, this can take forever.

I think this is probably a regression. I have preview build 0.2.1831.0 installed on this machine too, and that doesn't seem to have the problem.

Originally created by @j4james on GitHub (Jul 31, 2019). Originally assigned to: @PankajBhojwani on GitHub. # Environment Windows build number: Version 10.0.18362.175 Windows Terminal version (if applicable): Commit a08666b58eb65b85ddf94e69892fa3e0a084ba98 # Steps to reproduce 1. Start the Windows Terminal (Dev Build). 2. Open an Ubuntu tab (or whatever Linux shell you have). 3. Do a bunch of directory listings that really fill up the scrollback buffer (the System32 directory is good for that). 4. Execute `printf "\e[3J"` to clear the scrollback buffer. # Expected behavior The scrollback buffer should be cleared and control returned to the user almost immediately. # Actual behavior The app essentially stops responding. It will return to normal eventually, but how long that takes depends on the speed of your computer and how full the scrollback was to start with. This might be a duplicate of one of the other freeze-on-exit bugs (e.g. #1445), since the terminal seems to generate an erase scrollback call whenever you exit. But it only happens when actually typing `exit` in the shell - closing the tab directly works OK. From what I've been able to determine, the source of the problem is in the `Terminal::EraseInDisplay` method. When the eraseType is `EraseType::Scrollback`, it performs a loop to clear every line of the scrollback: https://github.com/microsoft/terminal/blob/a08666b58eb65b85ddf94e69892fa3e0a084ba98/src/cascadia/TerminalCore/TerminalApi.cpp#L340-L345 Note that the _eraseIter_ `OutputCellIterator` is set to the size of the full area being cleared, but a `_buffer->Write` call is made with that iterator for every line. Each one of those calls is enough to clear the entire area, so it's essentially performing a huge write operation over and over again. If your scrollback buffer is large, this can take forever. I think this is probably a regression. I have preview build 0.2.1831.0 installed on this machine too, and that doesn't seem to have the problem.
claunia commented 2026-01-30 23:11:25 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Jul 31, 2019):

I don't know why I didn't check this before, but I see now that the Terminal::EraseInDisplay method was only just added in PR #2144, so this can't be a duplicate of any of those older freezing bugs.

@j4james commented on GitHub (Jul 31, 2019): I don't know why I didn't check this before, but I see now that the `Terminal::EraseInDisplay` method was only just added in PR #2144, so this can't be a duplicate of any of those older freezing bugs.
claunia commented 2026-01-30 23:11:25 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Jul 31, 2019):

@PankajBhojwani is taking a look at this. Thanks for the quick catch!

@DHowett-MSFT commented on GitHub (Jul 31, 2019): @PankajBhojwani is taking a look at this. Thanks for the quick catch!
claunia commented 2026-01-30 23:11:26 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Jul 31, 2019):

This is my bad. I suggested that he make sure that we had enough bytes in the iterator to "fill the screen" under the erroneous assumption that it would take 1*rowLength every time. 😄

@DHowett-MSFT commented on GitHub (Jul 31, 2019): This is my bad. I suggested that he make sure that we had enough bytes in the iterator to "fill the screen" under the erroneous assumption that it would take `1*rowLength` every time. :smile:
claunia commented 2026-01-30 23:11:26 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Aug 1, 2019):

Triage 0.3 blocking

@DHowett-MSFT commented on GitHub (Aug 1, 2019): Triage 0.3 blocking
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-Performance Area-VT Issue-Bug Needs-Tag-Fix Product-Terminal Resolution-Fix-Committed Severity-Blocking
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#3036
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?