+++ This bug was initially created as a clone of Bug #652590 +++
Created attachment 459996[details]
Screenshot.png
Description of problem:
I have a VNC session configured in /etc/sysconfig/vncservers, and view it remotely using tigervnc. Both machines are freshly-installed with Fedora 14.
When I drag a window that's inside the VNC session quickly to the left via the VNC viewer, the entire window content becomes filled with artifacts from the move (see screenshot).
Using the 'Refresh Screen' option from the F8 menu does not clear it, so I guess it's a problem in the server rather than the viewer.
Version-Release number of selected component (if applicable):
tigervnc-1.0.90-0.22.20100813svn4123.fc14.x86_64
How reproducible:
100%
Steps to Reproduce:
1.Start VNC session
2.Start VNC viewer
3.Through viewer, drag a window sharply left
Actual results:
Artifacts.
Expected results:
No artifacts.
--- Additional comment from carlos@tarkus.se on 2011-01-27 04:32:03 EST ---
The same here.
Server:
FC14 + tigervnc-1.0.90-0.22.20100813svn4123.fc14.x86_64
It happens if you move the window fast enough to the left or right.
Tested with TightVNC client on Windows and vncviewer from tigervnc-1.0.0-3.fc12.x86_64 on Linux.
Step to reproduce:
1. Start VNC server with KDE (xstartup contains a single line "startkde&")
2. Connect viewer
3. Open konsole and drag it fast to the left or right
If you drag the window down out of the display and up again the windows content is redraw correctly again. Fast vertical movements work fine.
Somehow the horizontal screen update is screwed up.
--- Additional comment from twaugh@redhat.com on 2011-01-27 06:29:18 EST ---
It smells very much like memcpy being used when memmove should be...
--- Additional comment from atkac@redhat.com on 2011-01-27 11:29:50 EST ---
(In reply to comment #2)
> It smells very much like memcpy being used when memmove should be...
That's interesting idea, I will attach a library with modified memcpy to catch this issue.
--- Additional comment from atkac@redhat.com on 2011-01-27 11:33:30 EST ---
Created attachment 475635[details]
Library with modified memcpy
Can you please try to run Xvnc with this library?
Compile this source via "gcc -o memcpy.so -shared -fpic memcpy.c". Then simply start Xvnc with "LD_PRELOAD=/path/to/memcpy.so" and if there is really overlapping memcpy call then the modified memcpy() should print error + backtrace.
Thank you in advance.
--- Additional comment from carlos@tarkus.se on 2011-01-27 16:43:07 EST ---
You were right, there is an issue with memcpy. Here is a section of the dump:
Xvnc[0x43da79]
Overlapping memcpy!
dest: 0x7f7bd39f6ea4 src: 0x7f7bd39f6f54 n: 2660
/tarkus/slask/memcpy.so(memcpy+0x111)[0x7f7bd3c0a7fd]
Xvnc(fbBlt+0xdd)[0x44397d]
Xvnc(fbCopyWindowProc+0x155)[0x441875]
Xvnc(miCopyRegion+0x179)[0x589419]
Xvnc(fbCopyWindow+0xd9)[0x441af9]
Xvnc[0x50b657]
Xvnc[0x4c09ae]
Xvnc(miMoveWindow+0x1db)[0x59818b]
Xvnc(ConfigureWindow+0x517)[0x579ce7]
Xvnc(ProcConfigureWindow+0x88)[0x54eb08]
Xvnc(Dispatch+0x321)[0x554231]
Xvnc(main+0x35e)[0x50780e]
/lib64/libc.so.6(__libc_start_main+0xfd)[0x3ae5a1ee7d]
Xvnc[0x43da79]
Overlapping memcpy!
dest: 0x7f7bd39f88e4 src: 0x7f7bd39f8994 n: 2660
/tarkus/slask/memcpy.so(memcpy+0x111)[0x7f7bd3c0a7fd]
Xvnc(fbBlt+0xdd)[0x44397d]
Xvnc(fbCopyWindowProc+0x155)[0x441875]
Xvnc(miCopyRegion+0x179)[0x589419]
Xvnc(fbCopyWindow+0xd9)[0x441af9]
Xvnc[0x50b657]
Xvnc[0x4c09ae]
Xvnc(miMoveWindow+0x1db)[0x59818b]
Xvnc(ConfigureWindow+0x517)[0x579ce7]
Xvnc(ProcConfigureWindow+0x88)[0x54eb08]
Xvnc(Dispatch+0x321)[0x554231]
Xvnc(main+0x35e)[0x50780e]
/lib64/libc.so.6(__libc_start_main+0xfd)[0x3ae5a1ee7d]
Xvnc[0x43da79]
Overlapping memcpy!
dest: 0x7f7bd39fa324 src: 0x7f7bd39fa3d4 n: 2660
/tarkus/slask/memcpy.so(memcpy+0x111)[0x7f7bd3c0a7fd]
Xvnc(fbBlt+0xdd)[0x44397d]
Xvnc(fbCopyWindowProc+0x155)[0x441875]
Xvnc(miCopyRegion+0x179)[0x589419]
Xvnc(fbCopyWindow+0xd9)[0x441af9]
Xvnc[0x50b657]
Xvnc[0x4c09ae]
Xvnc(miMoveWindow+0x1db)[0x59818b]
Xvnc(ConfigureWindow+0x517)[0x579ce7]
Xvnc(ProcConfigureWindow+0x88)[0x54eb08]
--- Additional comment from updates@fedoraproject.org on 2011-04-13 11:17:46 EDT ---
tigervnc-1.0.90-3.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/tigervnc-1.0.90-3.fc15
--- Additional comment from updates@fedoraproject.org on 2011-04-13 11:19:04 EDT ---
tigervnc-1.0.90-0.25.20100813svn4123.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/tigervnc-1.0.90-0.25.20100813svn4123.fc14
--- Additional comment from carlos@tarkus.se on 2011-04-13 15:31:04 EDT ---
Just tested on FC14. Works fine for me.
The only (minor) detail was an error in the compilation, a conflict of socklen_t declaration between common/os/net.h and /usr/include/bits/socket.h. Apparently configure didn't managed to set HAVE_SOCKLEN_T.
--- Additional comment from updates@fedoraproject.org on 2011-04-13 16:49:57 EDT ---
Package tigervnc-1.0.90-0.25.20100813svn4123.fc14:
* should fix your issue,
* was pushed to the Fedora 14 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing tigervnc-1.0.90-0.25.20100813svn4123.fc14'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/tigervnc-1.0.90-0.25.20100813svn4123.fc14
then log in and leave karma (feedback).
--- Additional comment from twaugh@redhat.com on 2011-04-14 04:23:07 EDT ---
Fixes it here. Thanks!
--- Additional comment from atkac@redhat.com on 2011-04-15 04:12:29 EDT ---
(In reply to comment #8)
> Just tested on FC14. Works fine for me.
>
> The only (minor) detail was an error in the compilation, a conflict of
> socklen_t declaration between common/os/net.h and /usr/include/bits/socket.h.
> Apparently configure didn't managed to set HAVE_SOCKLEN_T.
In my opinion this error is present because you don't have g++ installed (gcc-c++ package).
--- Additional comment from updates@fedoraproject.org on 2011-04-19 15:28:57 EDT ---
tigervnc-1.0.90-0.25.20100813svn4123.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.
--- Additional comment from updates@fedoraproject.org on 2011-04-19 23:17:37 EDT ---
tigervnc-1.0.90-3.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.
--- Additional comment from pholica@redhat.com on 2011-07-20 04:08:04 EDT ---
Created attachment 513945[details]
Xvnc.png
Hello, I've just hit similar bug on Fedora-15 with tigervnc-server-minimal-1.0.90-4.fc15.x86_64 when no window manager is used, on TWM or on fluxbox when moving windows.
Attaching screenshot. Look on the decoration of inactive xterm.
--- Additional comment from landshark666@gmail.com on 2011-08-15 14:55:31 EDT ---
Created attachment 518313[details]
VNC graphical artifacts
I've been experiencing the same problem since upgrading to FC 15. I'm using fluxbox-1.3.1-1.fc15 and tigervnc-1.0.90-4.fc15. I've also attached a screenshot (Xvnc2.png). Whether the problem is in fluxbox or tigervnc I do not know. I've tried various themes under fluxbox and they all exhibit the problem. I tend to think it's the VNC server since you can see corruption on the inside edge of the xterm scrollbar, not just the window edges.
I've tried a few different VNC viewers to see if that could be the cause and they both see the artifacts (tightvnc viewer, realvnc viewer).
--- Additional comment from atkac@redhat.com on 2011-08-30 07:14:58 EDT ---
Issues written in comments #14 and #15 are different from the original one. The original issue was that dragging windows to left created artifacts. Your issue is that some parts of the windows are not rendered correctly.

I think we may be experiencing a similar problem in Fedora 16 using tigervnc-1.1.0-3.fc16.x86_64. The window borders are easily corrupted. If you move
one window over another window and then slide it off, the window borders are corrupted in the window that was temporarily obscured. It can be fixed by moving that window a small amount (which seems to cause a refresh).
Is there any fix for this? In case it matters, this is using the fvwm
window manager.

FYI, I tested tigervnc version 1.2.0, and it has the same bug.
Is there any way to escalate this issue? There's basically no working
Xvnc in Fedora 16. This is a real problem for us. I guess my next step is to
try other VNC servers.
Thanks,
Andy

Thanks. I tried using turbovnc. That does not have the bug, but it does not understand modern fonts, so it is not a good solution.
I also tried back-rev versions of tigervnc. If I install the Fedora 14 binary rpms on Fedora 16, they work fine (tigervnc-server-minimal-1.0.90-0.25.20100813svn4123.fc14.x86_64.rpm and tigervnc-server-1.0.90-0.25.20100813svn4123.fc14.x86_64.rpm).
I also tried the Fedora 15 versions, and they are buggy. I tried
both tigervnc-server-minimal-1.0.90-3.fc15.x86_64.rpm and tigervnc-server-minimal-1.1.0-1.fc15.x86_64.rpm, and neither works properly.
Is is interesting and surprising that the bug was introduced between tigervnc-server-minimal-1.0.90-0.25.20100813svn4123.fc14.x86_64.rpm and tigervnc-server-minimal-1.0.90-3.fc15.x86_64.rpm, since they are both ostensibly 1.0.90. Despite the similar version, there appear to have been many changes.
I would guess that the same bug persists in Rawhide.
Let me know if there's anything else I can do to help troubleshoot.
Thaks,
Andy

Andy,
Thanks for the helpful insight regarding the version that worked. It appears that TigerVNC commit 4220 is the cause of the rendering artifacts in the window decorations. I'm not entirely sure if it's correct to simply revert that change though. So far I have not seen any issues after doing so, but that commit was implemented to address another issue. I've submitted the issue to the tigervnc-devel mailing list so that the other devs can have a look at this but at least it's clear now where the problem stems from now. I'll attach a patch if you'd like to test it.
Kudos for picking up on that older version!
Thanks,
-brian

Created attachment 595310[details]
Modifies the change made in TigerVNC commit r4220.
Modifies the change made in TigerVNC commit r4220. Appears to fix this issue but may regress back to the issue r4220 addressed.
Adam,
Since you committed r4220, can you please review this?
Thanks,
-brian

(In reply to comment #7)
> Created attachment 595310[details]
> Modifies the change made in TigerVNC commit r4220.
>
> Modifies the change made in TigerVNC commit r4220. Appears to fix this
> issue but may regress back to the issue r4220 addressed.
>
> Adam,
>
> Since you committed r4220, can you please review this?
I just posted improved version of the patch to tigervnc-devel list which should fix both issues (artefacts + XDrawArc crashes). However it needs more testing before I can release it as update for Fedora...

This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '16'.
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 prior to Fedora 16's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 16 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 to click on
"Clone This Bug" and open it against that version of Fedora.
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.
The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping