Bug 1036229

Can you please attach a screenshot? What Xorg graphics driver do you use? Problem with corrupted display is usually a bug in the driver.

I am using Xvnc.  I will attach a screenshot the next time I notice it.

Created attachment 831726 [details]
snapshot of an xterm exhibiting corruption

Note the repetition of "retrieving revision 1.34" at the bottom
and the corruption of the "=" separator bars on the right side.

I tried using "xwd" to capture this, but the problems never appear
in the xwd file.  They remain visible on the screen, but the contents
of the xwd image are correct.

Do you know if this is an Xvnc problem or an xterm problem?

Also, I'm not certain of this, but I think the problem may occur only when part of the xterm window is obscured.

I'm not really familiar in how Xvnc works, but I think the fact that it's not visible in the xwd capture indicates a problem outside of xterm.

Reassigning to tigervnc, perhaps its maintainers will know better what's happening.

FYI, I tried to duplicate the problem in gnome-terminal and xfce4-terminal, and I don't see the corruption when I use those.  So it seems to me that it's either due to a bad interaction between xterm and Xvnc or it's truly an xterm problem.  I agree that the xwd behavior seems to suggest a server problem...

You could try different versions of xterm and see if some doesn't have this problem. Fedora builds can be found here:

http://koji.fedoraproject.org/koji/packageinfo?packageID=354

However, if it was a real bug in xterm, I'd expect to see more reports about it.

Another thing that will narrow down where the problem is: when you see this problem next, try getting the VNC viewer to 'refresh' (i.e. pull the entire screen from the server). With the native vncviewer client, F8 displays a menu for this.

I just grabbed the xterm-299 tarball from http://invisible-island.net/xterm and built that.  I see the same display corruption when part of the window is covered.  The xwd dumps contine to look good.  Moving the corrupted window seems to cause further corruption.

I don't know how many people are using xterm inside Xvnc.  I suspect it could be caused by a bad interaction between them.  Does anybody have any ideas on how to debug this?

I'd switch to rxvt, but we use xterm's ability to log to a file.  I don't think rxvt supports that.  But rxvt does not show the same corruption.  It is pretty easily repeatable with xterm under Xvnc.

One other thought: this seems to occur only when part of the xterm window is obscured.  For the vast majority of people who use click to focus, that is an unlikely scenario, since the act of selecting the xterm for focus by clicking on it will bring it to the front.  I am using fvwm2 with the focus following the mouse, so I can easily type into an xterm that is not in front.  Perhaps that explains why nobody else is noticing this.

Thanks,
Andy

(In reply to Tim Waugh from comment #8)
> Another thing that will narrow down where the problem is: when you see this
> problem next, try getting the VNC viewer to 'refresh' (i.e. pull the entire
> screen from the server). With the native vncviewer client, F8 displays a
> menu for this.

When I use the VNC menu "Refresh Screen" selection, the corruption disappears.  So I guess this is an Xvnc bug.  I don't know why other terminal programs don't have this problem...

Thanks,
Andy

Please post the output of vncviewer, both the starting lines when the connection is initiated, and any lines that occur at the same time as the display corruption.

Here is the entire output of vncviewer during a very brief session where I connect, do something that causes corruption, and then exit the session:

TigerVNC Viewer 64-bit v1.3.0 (20130924)
Built on Sep 24 2013 at 16:32:56
Copyright (C) 1999-2011 TigerVNC Team and many others (see README.txt)
See http://www.tigervnc.org for information on TigerVNC.

Tue Dec  3 10:46:03 2013
 CConn:       connected to host localhost port 5913
 CConnection: Server supports RFB protocol version 3.8
 CConnection: Using RFB protocol version 3.8

Tue Dec  3 10:46:09 2013
 PlatformPixelBuffer: Using default colormap and visual, TrueColor, depth 24.

Tue Dec  3 10:46:10 2013
 DesktopWindow: Adjusting window size to avoid accidental full screen request
 CConn:       Using pixel format depth 24 (32bpp) little-endian rgb888
 CConn:       Using Tight encoding
 Viewport:    Unexpected release of FLTK key code 65293 (0xff0d)
 CConn:       Enabling continuous updates


Note: I then connected briefly without doing anything to cause xterm corruption and exited.  The logs are essentially identical.  So I don't think any of the log messages are related to the corruption issue.

Thanks,
Andy

Now run "vncviewer -PreferredEncoding ZRLE ..." and see if you can get the corruption to happen.

I tried that.  It did not make any difference -- the corruption still occurs.  Here is the command output:

TigerVNC Viewer 64-bit v1.3.0 (20130924)
Built on Sep 24 2013 at 16:32:56
Copyright (C) 1999-2011 TigerVNC Team and many others (see README.txt)
See http://www.tigervnc.org for information on TigerVNC.

Tue Dec  3 11:49:36 2013
 CConn:       connected to host localhost port 5913
 CConnection: Server supports RFB protocol version 3.8
 CConnection: Using RFB protocol version 3.8

Tue Dec  3 11:49:40 2013
 PlatformPixelBuffer: Using default colormap and visual, TrueColor, depth 24.
 DesktopWindow: Adjusting window size to avoid accidental full screen request
 CConn:       Using pixel format depth 24 (32bpp) little-endian rgb888
 CConn:       Using ZRLE encoding
 Viewport:    Unexpected release of FLTK key code 65293 (0xff0d)
 CConn:       Enabling continuous updates

Thanks,
Andy

The corruption is also there with hextile.  I think with raw encoding, it may be OK.  Is there any shared code between Tight, ZRLE and hextile?

So raw encoding is definitely not showing the corruption?

Would be useful to see the network traffic from a short hextile session showing the corruption. Could you please try capturing it using e.g. tcpdump?:

tcpdump -s0 -U -w rfb.pcap port 5913

and then attach rfb.pcap to this report?

(Hmm, maybe it would be a good idea for me to teach rfbproxy how to read pcap files...)

Hi Tim,

The raw session looks OK to me.  I will attach the requested pcap file.

Thanks,
Andy

Created attachment 832216 [details]
tcpdump capture of hextile session exhibiting xterm corruption

This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.