Home
|
FAQ
|
Feedback
|
Licence
|
Updates
|
Mirrors
|
Keys
|
Links
|
Team
Download:
Stable
·
Snapshot
|
Docs
|
Privacy
|
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 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.)