+++ 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 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 on 2011-01-27 06:29:18 EST --- It smells very much like memcpy being used when memmove should be... --- Additional comment from atkac 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 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 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 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 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 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 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 on 2011-04-14 04:23:07 EDT --- Fixes it here. Thanks! --- Additional comment from atkac 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 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 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 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 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 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.
I tried using Xfce and GNOME instead of fvwm, and they all exhibit the same problem. Is there a patch for this? Thanks, Andy
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
Moving to Fedora 16, I will try to figure what causes this problem.
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
Thanks Brian. I tried the patch, and it seems to fix the bug. Regards, Andy
Keep an eye on the tigervnc-devel list. I don't think the issue is really resolved, the patch probably just reverts back to a different problem. -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...
Any updates on this issue? Is the patch merged upstream now?
(In reply to comment #11) > Any updates on this issue? Is the patch merged upstream now? Yes, it was committed in r4941: http://tigervnc.svn.sourceforge.net/viewvc/tigervnc?view=revision&revision=4941
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
This is already fixed in tigervnc-1.2.80-0.6.20121126svn5015.fc18