Home |
Licence |
FAQ |
Docs |
Download |
Keys |
Links
Mirrors |
Updates |
Feedback |
Changes |
Wishlist |
Team
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 231 (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'.)
Audit trail for this bug.