Bug Report: if historySize >= 32728 a maximize doesn't redraw the terminal

[mcornella]

Environment

Windows build number: 10.0.18980.1
Windows Terminal version (if applicable): 0.4.2382.0

Any other software?

Steps to reproduce

1. Set historySize of a profile to 32728 or bigger.
2. Open a tab for that profile.
3. Run commands so that there is a bunch of scroll space (running nano on Ubuntu is easier).
4. Maximize the window.

Expected behavior

The terminal should redraw itself to occupy all the available space.

Actual behavior

The terminal keeps using the previously available space, not occupying the extra one. Some screenshots:

1. After maximizing on Ubuntu:
   

2. After maximizing on cmd:
   
   (Note the last dir output kept going but it was cut midway)

Other relevant information

A manual resize of the window does correctly trigger a redraw on Ubuntu. Not on cmd, which just keeps using the window space it had when the tab was opened.

[DHowett-MSFT]

Well, that's a thinker.

[j4james]

Pretty much everything in the terminal implementation is a short, and while the initial history size is clamped, that's not enough to prevent an overflow when values are added. In this particular case, I believe the overflow is happening here:

terminal/src/cascadia/TerminalCore/Terminal.cpp

Line 167 in 4217bed

const short newBufferHeight = viewportSize.Y + _scrollbackLines;

Clamping that result to SHORT_MAX seems to fix the issue, but I wouldn't want to bet on that being the only place that needs clamping. Conhost avoids the issue by limiting the scrollback to 9999, which seems like a safer approach.

[zadjii-msft]

Welp, that's certainly my fault there. That's definitely wrong there, good find.

I think we should definitely make sure to use this issue as a chance to go through and audit some of our math in the Terminal code and make sure we're safemathing/clamping it. I clearly didn't do that originally, and we should be.

IIRC technically only the propsheet limits you to 9999 rows for conhost. I believe if you edit the registry directly, you can sidestep that to get to SHORT_MAX.

[j4james]

IIRC technically only the propsheet limits you to 9999 rows for conhost. I believe if you edit the registry directly, you can sidestep that to get to SHORT_MAX.

Yeah, you're right. But that means conhost likely has many issues like this too, and I suspect it's going to be a nightmare to audit.

Just look at AdjustCursorPosition as one example. That looks like it has several potential overflows, but I'm guessing the end result is still OK because of the way two's complement works (although technically it may be undefined behaviour). If you started clamping all of those calculations, though, it would probably cause more problems than it solved.

Personally I'd just clamp the initial buffer size to something like 30000, if that meant we could avoid having to deal with all those edge cases.

[ghost]

🎉This issue was addressed in #4964, which has now been successfully released as Windows Terminal Preview v0.10.781.0.:tada:

Handy links:

• Release Notes
• Store Download