GNOME Bugzilla – Bug 670037
Off-by-one error in interpretation of ECH (erase character)
Last modified: 2014-04-06 17:45:06 UTC
VTE doesn't correctly interpret the ECH (CSI Ps X) sequence with back-color erase. If the last cell to be erased (the Ps'th cell) is uninitialized, VTE does not fill it with the background color. To be correct, VTE should clear and fill all Ps cells with the background color. Example #1: Run this command: printf '\ec\e[2;1H\e[0;44m\e[3X\n\e[0m' What should happen: First line should be blank. Second line should have three cells of blue. Third line should have the shell prompt again. (This is the behavior of xterm and rxvt.) What happens in gnome-terminal: The second line only has two cells of blue. ====== Example #2: Run this command: printf '\ec\e[2;1H\e[0;44mabc\e[2;1H\e[3X\n\e[0m' What should happen: Same as example #1. What happens in gnome-terminal: This time gnome-terminal gets it correct (three cells of blue), because we initialized the contents of those cells to "abc" before erasing them.
Created attachment 207822 [details] [review] patch Yeah, it’s a clear off-by-one bug; this patch fixes it.
Confirmed. And the patch fixed it. Running the testcase in vteapp under valgrind shows a more serious problem in that it doesn't do anything resembling what it's supposed to do; instead just cleaning the screen and putting the prompt about halfway to the right side on the 1st line... There are no invalid reads etc. except for the known problem with vte_terminal_match_hilite_update().
(In reply to comment #2) > Running the testcase in vteapp under valgrind shows a more serious problem in > that it doesn't do anything resembling what it's supposed to do; instead just > cleaning the screen and putting the prompt about halfway to the right side on > the 1st line... I see what you mean. Actually, valgrind makes no difference: I see this both inside and outside valgrind, if and only if G_DEBUG=gc-friendly is set. But surely that’s a separate bug?
Fixed on vte-0-32 and vte-next.