GNOME Bugzilla – Bug 686097
screen not redrawn correctly when using mosh
Last modified: 2013-10-19 19:22:51 UTC
When using some programs over mosh (http://mosh.mit.edu/), vte often fails to redraw the screen correctly -- for example, only the top 1-3 pixels of a line are updated, or the bottom half of a line... So far I've seen it happen with mosh+tmux+weechat and mosh+tmux+ginsu, but it never happens with bare tmux+anyapp. I am sure this is not a bug in mosh, since the glitches go away as soon as I try to make a screenshot of the terminal. Attached photos of the glitch in ginsu (which triggers the bug very often) and of the same area rendered correctly. vte 0.34.0 gnome-terminal 3.6.0
Created attachment 226386 [details] Example
Can you run mosh+tmux+ginsu (or any other app that reproduces, preferably quickly) inside script(1) to get a log (possibly with timing info even), and see if replaying that log in plain vte (no mosh/tmux) shows the bug again? Also, does this happen in earlier vte versions too? Can you try 0.32 ?
Yes, it happens when replaying the log too, in vte 0.32 [gtk3], and in 0.28 [gtk2 - Xfce Terminal] as well. Works fine in Xterm.
Created attachment 226390 [details] Example typescript Typescript that triggers this bug (recorded Ginsu in tmux in mosh, in a 80x24 terminal)
It's worse that just those occasional pixel droppings; actually if I pause the replay (Ctrl-S) and then highligh text, it reveals that the actual text at those positions is different from what's shown before the highlighting (even happens before the pixel droppings appear on scrolling up).
Could you record *two* script(1) logs (with timing), one with mosh+tmux+ginsu showing the bug, the other one just tmux+ginsu *without* mosh, _doing the same thing_ (approx.) so that I can try and compare the outputs ? Thanks!
Created attachment 226430 [details] Example with and without mosh Attached two recordings of clients attached to the same tmux session -- one over mosh, the other over plain ssh, displaying the same program output. (In 90x35 terminals.)
Hmm they're actually very different... :/ What's the value of the TERM env variable inside mosh, inside tmux, inside mosh+tmux ?
Also, I just tested ginsu over mosh *without* tmux, and I see the same problem. (In reply to comment #8) > Hmm they're actually very different... :/ I seem to remember that mosh performs terminal emulation entirely server-side, and the client only receives updates to the screen buffer, which would explain the large differences. > What's the value of the TERM env variable inside mosh, inside tmux, inside > mosh+tmux ? "xterm-256color" locally, over mosh, and over ssh. "screen-256color" inside tmux (over both mosh and ssh; it doesn't change when attaching). Both machines run Linux and have the usual terminfo descriptions installed. (Not that it would matter, I think. gnome-terminal seems to interpret things fine, something just causes it to not draw them on screen right...)
Created attachment 243746 [details] A tarball containing test output which sometimes breaks vte rendering I also ran into this issue. I can reproduce it on the following Platforms: Arch Linux, Gnome-Terminal 3.8.1, VTE 0.34.4 Arch Linux, ./src/vte, VTE HEAD b7b11d0188 Debian Squeeze, Gnome-Terminal 2.30.2, VTE 0.24.3 I can't reproduce it on Ubuntu Quantal, Gnome-Terminal 3.6.0, 0.34.0 In the tarball there is some output which triggers the behavior which is visible in the screenshot. I am not sure whether this is actually an issue in vte or a problem with X rendering itself.
Created attachment 243761 [details] A simple example output triggering the weird rendering issue I was able to create a very short output sequence which triggers this problem. While trying to reproduce it, it seems that a necessary condition for the rendering issue to occur is that a part of the terminal gets scrolled away while another part of the terminal (which was stationary during the scrolling) gets overwritten. (Obviously I can only guess that this is a necessary condition, I may just have been out of luck trying to reproduce it without that)
Hopefully this will be the last addition for now. It also seems that timing is important for this bug to happen. Using "cat setup trigger" the glitch will not occur. Using "cat setup && sleep 1 && cat trigger" it occurs on susceptible platforms. (Also, slowly writing the trigger file to the terminal byte by byte causes the terminal not to do any scrolling at all, which could be considered a bug. The original rendering issue doesn't appear in that case, however that might be because there was no scrolling involved)
I'm hitting this regularly on Fedora 19 on at a couple of different installs. Where i'm seeing it now, VTE 0.34.6, gnome-terminal 3.8.4
I suspect this is a dupe of bug 542087. Could you guys please try that patch from the 15th comment? (Or test the behavior on Ubuntu >= 12.04, which already includes that patch.)
Doesn't help, sadly. I've patched both vte2 and vte3 and the bug is still there on both gnome-terminal and xfce4-terminal. One of the easiest ways to get it is to attach tmux after connecting via mosh and then create a 7th window. I have a couple of screenshots to illustrate that, but I see no way to attach them here.
Hi Von, I've tried the test scripts from comments 4, 10 and 11, on top of 0.34.9 with and without the patch. In all cases, the patch fixes the problem for me. Also, Christian in comment 10 mentions that he can't reproduce the problem on Ubuntu, which - knowing that Ubuntu includes this patch - also makes it likely that the patch is okay. Deploying a new vte library is not necessarily as easy as one might think. E.g. with gnome-terminal, you have to quit all instances of the terminal and then start again, or follow the instructions at https://wiki.gnome.org/Apps/Terminal/Debugging (I have no info about xfce4-terminal). Otherwise it just keeps using the old Vte. I see a chance that perhaps you didn't install the new version correctly, or your terminal didn't catch up with the change. Could you maybe just execute ./src/vte2_90 from the source tree (after compiling) and see how this works? If this one is fixed then you didn't properly update the library or restart the terminals. If still broken then we still have an unresolved issue. In this case could you please provide detailed (keypress by keypress) instructions on how to reproduce it, or attach a timed output of "script" as previous commenters did? I'd like to see it happen, but I don't know barely anything about tmux or mosh, I don't know where to start based on your vague instructions.
Can confirm that patch in bug 542087 comment 15 fixes this issue.
Yes, running the binary right after compiling it, I can confirm that the bug isn't there any more after applying patch from bug 542087 comment 15. Thanks for the suggestion, should have started with using that instead of building packages.
Hooray! :) *** This bug has been marked as a duplicate of bug 542087 ***