After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 553971 - escape sequences occasionally printed to display when launching tmux
escape sequences occasionally printed to display when launching tmux
Status: RESOLVED FIXED
Product: vte
Classification: Core
Component: general
0.17.x
Other All
: Normal minor
: ---
Assigned To: VTE Maintainers
VTE Maintainers
[fixed:vteparser]
Depends on: vteparser
Blocks:
 
 
Reported: 2008-09-26 17:12 UTC by Wayne Sierke
Modified: 2018-03-27 17:46 UTC
See Also:
GNOME target: ---
GNOME version: 2.21/2.22



Description Wayne Sierke 2008-09-26 17:12:18 UTC
Please describe the problem:
Using tmux in gnome-terminal on FreeBSD 7 STABLE. Upon launching a new tmux session, it in part issues a series of cursor positionings followed by a string of spaces on successive lines down the display to erase it. Occasionally it leaves text like ";1H" at the left-most edge of one of the lines, presumably the trailing part of one of the ^[[line;1H positioning sequences.

Steps to reproduce:
1. Open a gnome-terminal window
2. launch tmux
3. look for extraneous content on the display
4. exit the tmux session and repeat from (2) a couple of dozen times
5. adjust the window width by 1, repeat from (2)
6. why stop now when you're having so much fun?

Actual results:
Occasionally, with the right combination of terminal window size and phase of the moon, some text appears on the screen in a position which ought to be blank.

Expected results:


Does this happen every time?
This is an intermittent issue and appears to be sensitive to at least the size of the gnome-terminal window. I've witnessed it on and off since starting to use tmux about a month ago but only just began to pay careful attention to the exact circumstances that produce it. For a while it only appeared to be happening on ssh sessions to a system running under VMWare, however I've since been able to confirm the issue on simple local terminal sessions as well as ssh sessions to non-vm systems. At times I've witnessed high incident rates, other times it has proven difficult to reproduce. I suspect that increased graphics/cpu loading might increase the chances of the errant text appearing.

All of which seems to suggest a timing-related issue. Goody.

Other information:
Below is a script(1) capture of a tmux session to provide an example of how tmux initialises the terminal. Here tmux is launched in a 32x5 gnome-terminal window, then immediately exited with ^d. Note that there is only one actual caret character (^) where the ^D is printed, all the others are control characters. Further, the lines ending in \ are lines broken by me for improved legibility, other line breaks are as originally captured.

%tmux^M^M
^[[!p^[[?3;4l^[[4l^[>^[[?1h^[=^[(B^[)0^[[H^[[2J^[]0;0:0:csh - ""^G\
^[[1;4r^[[1;1H^[[?25l^[[?1000l                                ^[[2;1H\
                                ^[[3;1H\
                                ^[[4;1H\
                                ^[[1;4r^[[1;1H^[[?25h^[[1;4r^[[1;1H\
^[[?25l^[[?1000l^[[30m^[[42m\
^[[5;1H0:csh*          ^[[5;17H 00:57 27-Sep-08^[[39m^[[49m^[[1;4r\
^[[1;1H^[[?25h^[[?25lYou have mail.^[[1;1H
^[[?25h^[[?25l%^[[?25h^[[?25l^D^[[2;3H^[[2;2H^[[?25h^[[?25lexit^[[2;1H
^[[?25h^[[1;5r^[[?1l^[>^[[H^[[2J^[[?25h^[[m[exited]^M
%


Tabulated below is a list showing the display size of the terminal window, the text left on the display, the row that the text is displayed on (always starting at the column position 1) and an 'X' to indicate that the status display drawn by tmux on the bottom line of the window was overwritten by spaces (in black and overwriting the normally green background status text).

As far as was tested, for a given column-size, increasing the row-size above those listed results in the text being displayed on the same row as the for the highest row-size listed.

Most of these results are obtained on a FreeBSD system as indicated. I also managed to reproduce the issue on an Ubuntu system running in VMware Player.

Gnome-Terminal(2.22.2)/Gnome(2.22.2)/FreeBSD-7 STABLE
=====================================================

171x38	;1H	36
171x37	;1H	35	X
171x36	35r	35	X

166x39	H	37
166x38	H	36	X
166x37	r	36	X

165x27	H	25
165x26	H	24	X
165x25	r	24	X

162x14	H	12
162x13	r	12	X

157x41	39;1H	39
157x40	39;1H	39	X
157x39	1;38r	38	X

149x16	H	14
149x15	H	13
149x14	r	13	X

89x46	H	44
89x45	H	43	X
89x44	r	43	X


Gnome-Terminal(2.18.0)/Gnome(2.18.1)/Ubuntu(7.04)/VMPlayer(2.0.1)/WinXP(Pro/SP2)
================================================================================

87x49	1H	22
87x24	1H	22
87x23	1H	21	X
87x22	1r	21	X

One final twist is that the results on the FreeBSD system (not tested on Ubuntu) are affected by whether operating as user or root in the gnome-terminal window. The above results are listed operating as user. When operating as root, the first character of the text listed in the table is not displayed. e.g. for a terminal size of 157x41, the text displayed is 9;1H rather than 39;1H.
Comment 1 Christian Persch 2008-09-26 18:04:27 UTC
-> vte
Comment 2 Wayne Sierke 2008-09-28 04:55:33 UTC
Some further information:

 - Testing was with tmux-0.4a - installed package on FreeBSD, compiled from source on Ubuntu
 - The window size required to induce symptoms appears to be system-dependent. e.g. a window of width 87 induces the symptom on my Ubuntu system but not on my FreeBSD system, vice versa for a width of 89.
 - While the probability of the errant text appearing is < 1, it is completely consistent (for a given set of conditions) when it does occur. Although this doesn't also apply fully to the status line overwrite, this is more difficult to interpret since the status bar gets updated as a result of both X events and tmux events.
 - I am as yet unable to reproduce the symptoms:
   - by issuing the same byte sequence as captured by script(1) directly to gnome-terminal using cat(1)
   - in an xterm window
   - by attaching to an existing tmux session (even one just detached which produced the symptom when it was launched, and in the same gnome-terminal window) even though the differences in the byte sequence issued appear to be quite trivial.

I mentioned in the original report that a difference in the errant text is observed depending on whether operating as a user or as root. I have also since observed that the errant text varies between launching tmux with just: "tmux" and with: tmux new 'sleep 1'

(Note that 'tmux' and 'tmux new' are equivalent and both exhibit the same symptom.)

On my FreeBSD system, launching just 'tmux' (or 'tmux new') in a 171x37 window results in the errant text ";1H" while launching as: tmux new 'sleep 1' results in the errant text "36;1H" (on line 35).

Size	tmux new	tmux new 'sleep 1'
171x38	;1H	36	36;1H	36
171x37	;1H	35	36;1H	35
171x36	35r	35	1;35r	35

Similarly on my Ubuntu system:
Size	tmux new	tmux new 'sleep 1'
87x23	1H	21	;1H	21
Comment 3 Christian Persch 2015-12-26 13:07:14 UTC
Reproducible on vte git master?
Comment 4 Christian Persch 2018-03-27 17:46:41 UTC
Should be fixed on git master, if it was still present.