TigerVNC server (1.9.0) crashes when spanning monitors fullscreen and a monitor disconnects

[jsela...@gmail.com]

Been seeing this issue lately, and it's reproducible -- it doesn't crash every single time, but quite often.
Has anyone else seen this, or know of known bugs that might be related?

The config:
Linux workstation running RHEL 7.5 (3.10.0-862.3.2.el7.x86_64)
Xorg 1.19.5-5
mate 1.16.1-1
tigervnc 1.9.0-1
GPU: Nvidia Quadro K2200 (4G)
Nvidia driver 410.73
dual 4K monitors (Samsung U32H85x)

The steps:
- Login on console (:0) using mate
- configure displays as spanning - full screen size 7680x2160
(I'm not sure if 4K monitors are necessary, but spanning multiple monitors is)
- Start a tigervnc server (:1)
- Start a tigervnc client connected to :1, displaying on :0, and with these "Screen" options:
- Resize remote session to the local window
- Full screen mode
- Enable full screen mode over all monitors

Now, while the tigervnc client is being viewed, turn off one of the monitors.
This triggers RRScreenChangeNotify events on :0 and to the clients, including the tigervnc client, telling them to resize.

I monitored the events with xev, and the tigervnc client receives these events, which look expected (I'm not an expert on RandR event flow):
-------------
RRNotify event, serial 73, synthetic NO, window 0x2e000a3,
subtype XRRCrtcChangeNotifyEvent
crtc 539, mode None, rotation 0
x 0, y 0, width 0, height 0

RRNotify event, serial 73, synthetic NO, window 0x2e000a3,
subtype XRROutputChangeNotifyEvent
output DP-3, crtc None, mode None
rotation RR_Rotate_0
connection RR_Disconnected, subpixel_order SubPixelUnknown

RRScreenChangeNotify event, serial 73, synthetic NO, window 0x2e000a3,
root 0x240, timestamp 589674077, config_timestamp 589674077
size_index 0, subpixel_order SubPixelUnknown
rotation RR_Rotate_0
width 3840, height 2160, mwidth 1016, mheight 572
-------------

But, from inside the tigervnc server, I see these events (on the root window):

-------------
RRScreenChangeNotify event, serial 90, synthetic NO, window 0x268,
root 0x268, timestamp 589609838, config_timestamp 589609838
size_index 65535, subpixel_order SubPixelUnknown
rotation RR_Rotate_0
width 9281, height 2160, mwidth 2424, mheight 563

RRScreenChangeNotify event, serial 90, synthetic NO, window 0x268,
root 0x268, timestamp 589609838, config_timestamp 589675012
size_index 65535, subpixel_order SubPixelUnknown
rotation RR_Rotate_0
width 9281, height 2160, mwidth 2424, mheight 563

RRNotify event, serial 90, synthetic NO, window 0x268,
subtype XRRCrtcChangeNotifyEvent
crtc 664, mode None, rotation RR_Rotate_0
x 0, y 0, width 0, height 0

RRNotify event, serial 90, synthetic NO, window 0x268,
subtype XRROutputChangeNotifyEvent
output VNC-1, crtc None, mode None
rotation RR_Rotate_0
connection RR_Disconnected, subpixel_order SubPixelUnknown
-------------

Notice the oddball width of 9281? Where's that coming from?
And that number changes each time. Sometimes it's so big the vnc server rejects it with:
"RandR: Failed to resize screen to 49937x2160"

And other times the vnc server just segfaults with a backtrace like this (killing all clients):
-------------
(EE)
(EE) Backtrace:
(EE) 0: /usr/bin/Xvnc (xorg_backtrace+0x55) [0x5ce865]
(EE) 1: /usr/bin/Xvnc (0x400000+0x1d22d9) [0x5d22d9]
(EE) 2: /usr/lib64/libpthread.so.0 (0x7f9e5da36000+0xf680) [0x7f9e5da45680]
(EE) 3: /usr/lib64/libc.so.6 (0x7f9e5b56d000+0x14c72d) [0x7f9e5b6b972d]
(EE) 4: /usr/bin/Xvnc (_ZN3rfb21ModifiablePixelBuffer9imageRectERKNS_4RectEPKvi+0x126) [0x538ea6]
(EE) 5: /usr/bin/Xvnc (_ZN3rfb22ComparingUpdateTracker7compareEv+0xd0) [0x5415d0]
(EE) 6: /usr/bin/Xvnc (_ZN3rfb11VNCServerST11writeUpdateEv+0x210) [0x53f430]
(EE) 7: /usr/bin/Xvnc (_ZN3rfb11VNCServerST13handleTimeoutEPNS_5TimerE+0x48) [0x53f658]
(EE) 8: /usr/bin/Xvnc (_ZN3rfb5Timer13checkTimeoutsEv+0x97) [0x53d587]
(EE) 9: /usr/bin/Xvnc (_ZN3rfb11VNCServerST13checkTimeoutsEv+0x1d) [0x53dd1d]
(EE) 10: /usr/bin/Xvnc (_ZN14XserverDesktop12blockHandlerEPi+0x221) [0x52fc31]
(EE) 11: /usr/bin/Xvnc (vncCallBlockHandlers+0x27) [0x524227]
(EE) 12: /usr/bin/Xvnc (BlockHandler+0x56) [0x580d96]
(EE) 13: /usr/bin/Xvnc (WaitForSomething+0x79) [0x5cc6d9]
(EE) 14: /usr/bin/Xvnc (Dispatch+0xac) [0x57c1dc]
(EE) 15: /usr/bin/Xvnc (dix_main+0x3fa) [0x58039a]
(EE) 16: /usr/lib64/libc.so.6 (__libc_start_main+0xf5) [0x7f9e5b58f3d5]
(EE) 17: /usr/bin/Xvnc (0x400000+0x5017e) [0x45017e]
(EE)
(EE) Segmentation fault at address 0x7f9cab5f6f40
(EE)
Fatal server error:
(EE) Caught signal 11 (Segmentation fault). Server aborting
(EE)
-------------

The workaround I'm suggesting to people running into this is not use fullscreen mode spanning across multiple monitors. The VNC can be stretched all the way across, but kept windowed, and this doesn't happen.

Anyone heard or seen something like this before?

[Pierre Ossman]

On 27/02/2019 22:58, jsela...@gmail.com wrote:
> Been seeing this issue lately, and it's reproducible -- it doesn't crash every single time, but quite often.
> Has anyone else seen this, or know of known bugs that might be related?
>

As luck has it the crash was fixed here:

https://github.com/TigerVNC/tigervnc/commit/f81148c43a25d4c69e635b6ad13eab674b473aca

I'm not sure what caused the odd resize though. Have you checked the
client log output?

Regards
--
Pierre Ossman Software Development
Cendio AB https://cendio.com
Teknikringen 8 https://twitter.com/ThinLinc
583 30 Linköping https://facebook.com/ThinLinc
Phone: +46-13-214600

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[john.pe...@gmail.com]

On Friday, March 1, 2019 at 8:52:06 AM UTC-6, Pierre Ossman wrote:

That is fantastic! Is there a release that incorporates that fix? Or a date when one might be available?

Thanks,
jgp

[jsela...@gmail.com]

That's great, Pierre. Thanks!
I'm also very interested in knowing when that fix will be available.

Regarding your question:

>
> I'm not sure what caused the odd resize though. Have you checked the
> client log output?
>

Didn't think about that -- I was focusing only on the server log. I see very little in the client log though. I see this when the server reports "Failed to resize screen":

> CConn: SetDesktopSize failed: 3

But nothing else. When the server crashes though, we only see: "CConn: End of stream"

-Jeff

[Pierre Ossman]

On 01/03/2019 23:15, john.pe...@gmail.com wrote:
>
> That is fantastic! Is there a release that incorporates that fix? Or a date when one might be available?
>

No release yet, unfortunately. But I'm hoping we can get one out soon.

[Pierre Ossman]

Could you start the client with -Log *:stderr:100 and see if you get
something more?