[Bug 1022432] New: vncserver does not allow connection from 2nd time on
http://bugzilla.opensuse.org/show_bug.cgi?id=1022432 Bug ID: 1022432 Summary: vncserver does not allow connection from 2nd time on Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.2 Hardware: x86-64 OS: openSUSE 42.2 Status: NEW Severity: Major Priority: P5 - None Component: X.Org Assignee: xorg-maintainer-bugs@forge.provo.novell.com Reporter: hnch@gmx.net QA Contact: xorg-maintainer-bugs@forge.provo.novell.com Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.75 Safari/537.36 Build Identifier: vncserver allows connection from vncviewer at the first time, but immediately terminates connection from second attempt on. Logging in on 42.2 system from my local machine and starting vncserver: henning@deepthought:~> ssh -L 6100:localhost:6100 host113 Password: Last login: Sat Jan 28 11:08:05 2017 from <redacted> Have a lot of fun... henning@host113:~> vncserver -geometry 1280x720 :200 New 'host113:200 (henning)' desktop is host113:200 Starting applications specified in /home/henning/.vnc/xstartup Log file is /home/henning/.vnc/host113:200.log First connection from local machine works: henning@deepthought:~> vncviewer localhost:6100 Connected to RFB server, using protocol version 3.8 Performing standard VNC authentication Password: Authentication successful Desktop name "host113:200 (henning)" VNC server default format: 32 bits per pixel. Least significant byte first in each pixel. True colour: max red 255 green 255 blue 255, shift red 16 green 8 blue 0 Warning: Cannot convert string "-*-helvetica-bold-r-*-*-16-*-*-*-*-*-*-*" to type FontStruct Using default colormap which is TrueColor. Pixel format: 32 bits per pixel. Least significant byte first in each pixel. True colour: max red 255 green 255 blue 255, shift red 16 green 8 blue 0 Same machine: preferring raw encoding Second connection attempt: henning@deepthought:~> vncviewer localhost:6100 Connected to RFB server, using protocol version 3.8 Performing standard VNC authentication Password: Authentication successful Desktop name "host113:200 (henning)" VNC server default format: 32 bits per pixel. Least significant byte first in each pixel. True colour: max red 255 green 255 blue 255, shift red 16 green 8 blue 0 Warning: Cannot convert string "-*-helvetica-bold-r-*-*-16-*-*-*-*-*-*-*" to type FontStruct Using default colormap which is TrueColor. Pixel format: 32 bits per pixel. Least significant byte first in each pixel. True colour: max red 255 green 255 blue 255, shift red 16 green 8 blue 0 Same machine: preferring raw encoding vncviewer: VNC server closed connection I will attach server log. Reproducible: Always Steps to Reproduce: 1. vncserver -geometry 1280x720 :200 2. vncviewer localhost:6100 3. vncviewer localhost:6100 Actual Results: Connected to RFB server, using protocol version 3.8 Performing standard VNC authentication Password: Authentication successful Desktop name "host113:200 (henning)" VNC server default format: 32 bits per pixel. Least significant byte first in each pixel. True colour: max red 255 green 255 blue 255, shift red 16 green 8 blue 0 Warning: Cannot convert string "-*-helvetica-bold-r-*-*-16-*-*-*-*-*-*-*" to type FontStruct Using default colormap which is TrueColor. Pixel format: 32 bits per pixel. Least significant byte first in each pixel. True colour: max red 255 green 255 blue 255, shift red 16 green 8 blue 0 Same machine: preferring raw encoding vncviewer: VNC server closed connection Expected Results: Connected to RFB server, using protocol version 3.8 Performing standard VNC authentication Password: Authentication successful Desktop name "host113:200 (henning)" VNC server default format: 32 bits per pixel. Least significant byte first in each pixel. True colour: max red 255 green 255 blue 255, shift red 16 green 8 blue 0 Warning: Cannot convert string "-*-helvetica-bold-r-*-*-16-*-*-*-*-*-*-*" to type FontStruct Using default colormap which is TrueColor. Pixel format: 32 bits per pixel. Least significant byte first in each pixel. True colour: max red 255 green 255 blue 255, shift red 16 green 8 blue 0 Same machine: preferring raw encoding -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1022432 http://bugzilla.opensuse.org/show_bug.cgi?id=1022432#c1 --- Comment #1 from Henning Paul <hnch@gmx.net> --- Created attachment 711988 --> http://bugzilla.opensuse.org/attachment.cgi?id=711988&action=edit vncserver log file Sat Jan 28 13:12:04 2017 VNCSConnST: Server default pixel format depth 24 (32bpp) little-endian rgb888 VNCSConnST: Client pixel format depth 24 (32bpp) little-endian rgb888 Connections: closed: 127.0.0.1::44414 (Destination rect 13x21 at 0,-1 exceeds framebuffer 5x20) EncodeManager: Framebuffer updates: 0 EncodeManager: Total: 0 rects, 0 pixels EncodeManager: 0 B (1:-nan ratio) -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1022432 http://bugzilla.opensuse.org/show_bug.cgi?id=1022432#c2 --- Comment #2 from Henning Paul <hnch@gmx.net> --- Behaviour is the same if connecting through xrdp. That's how I encountered the problem in the first place. Updating xorg-x11-server to 1.19.1 from http://download.opensuse.org/repositories/X11:/XOrg did not fix the problem. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1022432 http://bugzilla.opensuse.org/show_bug.cgi?id=1022432#c3 --- Comment #3 from Henning Paul <hnch@gmx.net> --- Obviously openSUSE-SU-2017:0290-1 is the reason: I was able to reproduce the bug on a second system, but only after updating tigervnc from 1.6.0-3.1 to 1.6.0-6.1. With the old version everything works fine. By the way, in my last test, vnc allowed connecting twice and rejected from the third connection on. So if you are trying to reproduce the bug, please maybe try more often. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1022432 http://bugzilla.opensuse.org/show_bug.cgi?id=1022432#c4 --- Comment #4 from Henning Paul <hnch@gmx.net> --- Updating tigervnc to version 1.7.1 from http://download.opensuse.org/repositories/X11:/XOrg solves the problem. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1022432 Stefan Dirsch <sndirsch@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P5 - None |P3 - Medium CC| |msrb@suse.com -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1022432 http://bugzilla.opensuse.org/show_bug.cgi?id=1022432#c5 --- Comment #5 from Michal Srb <msrb@suse.com> --- I couldn't reproduce it with 1.7.1 either. If you are positive that the issue is gone, you can close the bug. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1022432 http://bugzilla.opensuse.org/show_bug.cgi?id=1022432#c6 --- Comment #6 from Henning Paul <hnch@gmx.net> --- Personally I could live with using version 1.7.1 from the Xorg repo, but Leap 42.2's 1.6.0-6.1 still shows the bug. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1022432 http://bugzilla.opensuse.org/show_bug.cgi?id=1022432#c7 Michal Srb <msrb@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |IN_PROGRESS --- Comment #7 from Michal Srb <msrb@suse.com> --- You are right, I kinda confused the update to 1.7.1 (which was just for factory) with recent security update (which was for all distributions). I was able to reproduce it with tigervnc 1.6.0. Easy steps to reproduce it: 1) Start Xvnc (either using xserver or directly), connect to it. 2) Start xterm in the session, move the window to be partially out of screen. 3) Keep pressing enter in the xterm until it starts scrolling. 4) As soon as the xterm start scrolling Xvnc terminates the connection. Xterm uses ProcCopyArea to scroll the content of its window, this copy rectangle is propagated to the damage handling in Xvnc and then it is incorrectly evaluated as broken because it attempts to copy rectangle that is partially exceeding the framebuffer. It happens in `ModifiablePixelBuffer` class which is used both by client and server. In case of client it is correct corrent to terminate, because it would mean something broken came over network, but in case of server it should just trim the rectangle and keep going. Apparently it is fixed in newer version, not sure if intentionally. I will backport or recreate the fix. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1022432 http://bugzilla.opensuse.org/show_bug.cgi?id=1022432#c8 Michal Srb <msrb@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|IN_PROGRESS |RESOLVED Resolution|--- |FIXED --- Comment #8 from Michal Srb <msrb@suse.com> --- Submitted fix to OpenSUSE: https://build.opensuse.org/request/show/453888 This issue does not happen in any version of SLES because they all have earlier versions of tigervnc which doesn't disconnect the client after (mis)detecting that copied rectangle was out of screen. -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠novell.com