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.
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.
It smells very much like memcpy being used when memmove should be...
(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.
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.
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]
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
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
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.
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).
Fixes it here. Thanks!
(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).
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.
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.
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.
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).
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.
New issues are tracked under bug #734424, closing this one.