Bulgarian mirror 10 Gbps

PuTTY bug assert-fail-newsavelines

Home | FAQ | Feedback | Licence | Updates | Mirrors | Keys | Links | Team
Download: Stable · Snapshot | Docs | Changes | Wishlist

We've had occasional reports of the failure of the following assertion:

terminal.c:559 (0.55), :454 (0.58)
count234(term->scrollback) <= newsavelines

Most of the reports we've had seem to also include a CPU-intensive delay at connection startup (possibly at other times too).

The only way we've found to reproduce this assertion failure is by configuring a negative number of lines in the scrollback. If the magnitude of the negative number is large, we see the delay at startup too.

On some platforms (including Windows), a very large positive scrollback setting can end up treated as a negative one, triggering this. This can happen for scrollback sizes of 2³¹ (2147483648) or greater. (You'd probably run out of physical memory before filling up such a ridiculously large scrollback buffer!) So don't do that, then.

We should probably be robust against silly configurations like this.

(Possibly related, although we've no hard evidence for this: assert-line-not-null.)

• OFA8A74C15.A4B5BE13-ON65256EF4.00210ED6-80256EF4.003C2FE1@in.ibm.com
  Telnet
• 2872.66.167.58.15.1094144958.squirrel@66.167.58.15
  0.55, "09-02-2004"; SSH
• F0652A9934B81649B13293685D1945E90199B261@WHQNT60.AAM.NET
  0.58, SSH, very large scrollback setting