GNOME Bugzilla – Bug 738964
Stream's tail advances its head
Last modified: 2014-11-20 20:44:20 UTC
Apply the attached patch, start vte, start vim or mc (or switch to alternate screen by some other means) => assertion fails. In the alternate screen's stream (why does it have any? I guess it shouldn't) the tail advances beyond the head. Not sure if it imposes runtime bugs or not, but nevertheless it should be fixed.
Created attachment 289080 [details] [review] trigger assertion failure (patch that imposes the bug; not a patch that fixes it :))
Definitely shouldn't happen. And we should assert that. Though, I don't think anything bad is happening right now. Haven't checked the code though.
The bug is not specific to the alternate screen. You can also trigger on the normal screen if your scrollback is very small. E.g. apply the patch, start ./src/vte-2.91 -n 30, press and hold Enter at the shell prompt. The problem is: _vte_ring_discard_one_row falsely assumes that the row to be discarded has already made it into the stream, it doesn't handle the case if it's still in ring's circular array (i.e. hasn't been frozen). On a slightly related note: To make vte easier to debug and less like to contain a nasty bug that relates to vte's height vs. powers of 2, I'd like to modify the circular buffer so that a row is frozen as soon as it scrolls out of the screen, rather than when it no longer fits in the ring. The ring's size could remain a power of 2, but it could also be changed to match the window height. I don't think doing an arbitrary "modulo" operand is noticeably slower than bitmask operations. Changing the ring size is a rare user-initiated event (window resize), so there's no need to optimize there for fewer mallocs either.
Created attachment 290790 [details] [review] Fix
Sounds good to me. Thanks.
Is this safe to put into 0-38 ? If so, please cherry-pick :-)
I'm planning to fix bug 740347 too, maybe more (the one-fd patch still crashes sometimes on some assertions), and will cherry-pick them all at once if they seem to be safe&stable. These are not critical at all, I'd rather go for absolutely sure than risking breaking anything in the stable branch. Is there a 0.38.3 planned?
Not exactly planned, but if enough good bug fixes pile up it may happen :-)