Rfb protocol error invalid message type 255

UltraVNC

1.1.8.0 protocol error

1.1.8.0 protocol error

Post by Rudi De Vos » 2013-01-08 21:47

rfb proto error found in 1.1.8.0

Re: 1.1.8.0 protocol error

Post by jbcollins » 2013-01-25 21:41

Re: 1.1.8.0 protocol error

Post by Rudi De Vos » 2013-01-28 12:18

Have you set an empty server passwd ?

Source was aleady modified, i will compîle some test version with fix and try
to upload it before the weekend

Re: 1.1.8.0 protocol error

Post by jbcollins » 2013-01-28 14:42

No i am using a set password.

It seems to work on the first connection i make but then if i close and make another connection to the same viewer i get this error.

Second time trying to connect i get the error: RFB protocol error: bad xrle data

Third time trying to connect i get this error: RFB protocol error: unknown message type 24

Re: 1.1.8.0 protocol error

Post by Rudi De Vos » 2013-02-04 21:57

Re: 1.1.8.0 protocol error

Post by jbcollins » 2013-02-07 09:05

Tried using the update executable (product version 1.1.8.1) and still getting the same thing. The very first connection from a windows 8 machine comes through ok but then any other connections from the same windows 8 machine fail with the following errors.

RFB protocol error: unknown message type 24

RFB protocol error: bad rectangle: 65280×6148 at 33316,1 exceeds 1920×1080

• Board index
• All times are UTC
• Delete cookies

Powered by phpBB® Forum Software © phpBB Limited

Источник

Rfb protocol error bad pixel format

RealVNC, RPi3, ESXi and Windows 7 VM — Bad Rectangles

I have an ESXi server on which I run a few VMs, one of which is the only Windows machine in the house, effectively. My MacBook is being repaired and whilst it is away, I thought I would try getting VNC working on my RPi3 so I can still use the Windows 7 VM when I need to.

The RPi3 is attached to a Motorola Laptop and is working fine.
I got RealVNC installed.
The VM has its desktop size set to 1366×768.

What I found was the first time i got it working it was great, after several connection attempts failed with RFB protocol error — bad rectangle

Since then I have not been able to get rid of the error and it has been unusable.

The VNC viewer window shows a double ghost image of the W7 VM desktop below which it says:
Attempting to reconnect to VNC server.
RFB protocol error: Bad rectangle: 16448×0 at 0,0 exceeds 1366×768

Bear in mind here that the VNC server is not actually running on the Windows machine, it is a function within the ESXi server, so pretty basic. It does however work flawlessly with Apple Remote Desktop and with the Remoter VNC client I have on my iPad. And as I said it did work once with RealVNC on the RPi3.

Has anyone come across this and worked out a work around or solved it?

Re: RealVNC, RPi3, ESXi and Windows 7 VM — Bad Rectangles

I gave up on RealVNC. And they won’t even speak to you unless you are trying to connect to a RealVNC server.

Xtightvncviewer works. sort of! Its a bit clunky to get a connection, but that’s OK. I don’t like not being able to have a full screen view. It has the option (allegedly!) as pressing F8 brings up a menu with a «Full screen» option but clicking it crashes/closes the viewer completely. Also trying to change the desktop resolution of the Windows VM at the other end causes the viewer to crash or close too.

Are there any recommendations for VNC viewers I might try instead?

Re: RealVNC, RPi3, ESXi and Windows 7 VM — Bad Rectangles

Result! I wanted to see what VNC related packages were installed on the Pi.
Found something installed called xvnc4viewer! Which works perfectly and yet claims to be RealVNC. When I tried starting the RealVNC viewer from the Raspbian GUI I couldn’t make it work. I don’t know if by started xvnc4viewer from the command line starts the same client in a different way, but it works, so I am happy now.

In comparison xtightvncviewer is just nasty.

Источник

TightVNC Bugs

Group

Searches

#1237 TightVNC 2.7.1, Windows 2008r2, RFB error, bad screen size

Hi,
I have problem with TightVNC 2.7.1 x64bit on Windows 2008 r2.
System:
— debian box, kvm-qemu
— clean install Windows 2008 r2
— all updates include optional
— TightVNC 2.7.1
— DFMirage Driver 2.0.301

Problem:
Before windows update everything was ok. After windows optional update I can no longer connect to the TightVNC server. From RealVNC Viewer I get error «RFB error: bad screen size 0x0». With TightVNC Viewer I get only toolbar from client, but without image.
It become independent of the two clean installed servers.

Discussion

We are seeing this same issue as well on almost identical configuration

Brand new machine, Windows 2008 r2
Initially setup with TightVNC 2.7.1 dn DFMirage. VNC was working fine.

We ran Windows Update to get current, and vnc no longer worked, would report Screen geometry of 0x0

We uninstalled 2.7.1, and installed 2.6.4 and VNC works

Attached is a log file from 2.7.1 when VNC was not working

[ 3560/ 476] 2013-04-29 11:29:09 + TightVNC Server Build on Apr 24 2013 at 15:15:50
[ 3560/ 476] 2013-04-29 11:29:09 + Stopping main RFB server
[ 3560/ 476] 2013-04-29 11:29:09 + Starting main RFB server
[ 3560/ 476] 2013-04-29 11:29:09 + Rfb server started at 0.0.0.0:5900
[ 3560/ 476] 2013-04-29 11:29:09 + Need to reconfigure extra RFB servers
[ 3560/ 476] 2013-04-29 11:29:09 + Stopping HTTP server
[ 3560/ 476] 2013-04-29 11:29:09 + Starting HTTP server
[ 3560/ 476] 2013-04-29 11:29:09 + Http server started
[ 3560/ 476] 2013-04-29 11:29:09 + Stopping control server
[ 3560/ 476] 2013-04-29 11:29:09 + Starting control server
[ 3560/ 476] 2013-04-29 11:29:09 + Control server started
[ 3560/ 3404] 2013-04-29 11:29:42 + Incoming rfb connection from 74.95.78.33
[ 3560/ 3592] 2013-04-29 11:29:46 ! write() function stopped because transport has not been initialized yet.
[ 3560/ 3592] 2013-04-29 11:29:46 + File transfer request handler created
[ 3560/ 3592] 2013-04-29 11:29:55 + Connection has been closed
[ 3560/ 3592] 2013-04-29 11:29:55 + File transfer request handler deleted
[ 568/ 4060] 2013-04-29 11:29:55 ! AnonymousPipe::read() failed (m_hRead = 0000000000000008)
[ 568/ 4060] 2013-04-29 11:29:55 ! The DesktopServerApplication dispatcher has failed with error: The Pipe’s read function failed after ReadFile calling (The pipe has been ended. (109))
[ 568/ 4060] 2013-04-29 11:29:55 ! An error has been occurred in the desktop server. Application will be closed.
[ 568/ 4060] 2013-04-29 11:29:55 + The DesktopServerApplication dispatcher has been stopped
[ 3560/ 1460] 2013-04-29 11:29:55 ! AnonymousPipe::read() failed (m_hRead = FFFFFFFFFFFFFFFF)
[ 3560/ 1460] 2013-04-29 11:29:55 ! The Pipe’s read function failed after ReadFile calling (The pipe has been ended. (109))
[ 3560/ 1460] 2013-04-29 11:29:55 ! The DesktopServerApplication dispatcher has failed with error: The ReconnectingChannel::read() function failed.
[ 3560/ 1460] 2013-04-29 11:29:55 ! onAbnormalDesktopTerminate() called
[ 3560/ 1460] 2013-04-29 11:29:55 ! Forced closing of pipe conections
[ 3560/ 1460] 2013-04-29 11:29:55 + The DesktopServerApplication dispatcher has been stopped
[ 3560/ 3064] 2013-04-29 11:29:55 + Connection has been closed
[ 3560/ 3404] 2013-04-29 11:30:26 + Incoming rfb connection from 74.95.78.33
[ 3560/ 3492] 2013-04-29 11:30:29 ! write() function stopped because transport has not been initialized yet.
[ 3560/ 3492] 2013-04-29 11:30:29 + File transfer request handler created
[ 3560/ 3492] 2013-04-29 11:30:41 + Connection has been closed
[ 3560/ 3492] 2013-04-29 11:30:41 + File transfer request handler deleted
[ 3264/ 4016] 2013-04-29 11:30:41 ! AnonymousPipe::read() failed (m_hRead = 0000000000000008)
[ 3264/ 4016] 2013-04-29 11:30:41 ! The DesktopServerApplication dispatcher has failed with error: The Pipe’s read function failed after ReadFile calling (The pipe has been ended. (109))
[ 3264/ 4016] 2013-04-29 11:30:41 ! An error has been occurred in the desktop server. Application will be closed.
[ 3264/ 4016] 2013-04-29 11:30:41 + The DesktopServerApplication dispatcher has been stopped
[ 3560/ 252] 2013-04-29 11:30:41 ! AnonymousPipe::read() failed (m_hRead = FFFFFFFFFFFFFFFF)
[ 3560/ 252] 2013-04-29 11:30:41 ! The Pipe’s read function failed after ReadFile calling (The pipe has been ended. (109))
[ 3560/ 252] 2013-04-29 11:30:41 ! The DesktopServerApplication dispatcher has failed with error: The ReconnectingChannel::read() function failed.
[ 3560/ 252] 2013-04-29 11:30:41 ! onAbnormalDesktopTerminate() called
[ 3560/ 252] 2013-04-29 11:30:41 ! Forced closing of pipe conections
[ 3560/ 252] 2013-04-29 11:30:41 + The DesktopServerApplication dispatcher has been stopped
[ 3560/ 3064] 2013-04-29 11:30:41 + Connection has been closed
[ 3560/ 2880] 2013-04-29 11:40:27 ! Exception in control client thread: «The Pipe’s read function failed after GetOverlappedResult calling (The pipe has been ended. (109))»

I have encountered exactly the same error described here on a Win7 64-bit Pro system. TightVNC 2.7.1 worked fine initially (with or without mirror driver) but after windows updates it would exhibit the 0x0 screen size error. Multiple re-installs and wipes of TightVNC settings had no effect, but downgrading to 2.6.4 resolved the issue immediately.

Источник

vncviewer fais vith «Rect too big»

Bug Description

Binary package hint: xvnc4viewer

package: xvnc4viewer 4.1.1+xorg1. 0.2-0ubuntu4

how to reproduce:

1. server is run on remote kde desktop using krfb with or without authentication . screen size: 1024×768
2. vncviewer is set to use xvnc4viewer backend though update- alternatives. client screen size 1440×900

Connecting to the server let you see the remote host screen and then crash with

VNC Viewer Free Edition 4.1.1 for X — built Jan 7 2007 17:30:38
Copyright (C) 2002-2005 RealVNC Ltd.
See http:// www.realvnc. com for information on VNC.

Sun May 27 19:02:43 2007
CConn: connected to host surya port 5900

Sun May 27 19:02:44 2007
CConnection: Server supports RFB protocol version 3.3
CConnection: Using RFB protocol version 3.3

Sun May 27 19:02:47 2007
TXImage: Using default colormap and visual, TrueColor, depth 24.
CConn: Using pixel format depth 6 (8bpp) rgb222
CConn: Using ZRLE encoding

Sun May 27 19:02:48 2007
CConn: Throughput 1957 kbit/s — changing to full colour
CConn: Using pixel format depth 24 (32bpp) little-endian rgb888
Rect too big: 2602×45584 at 25104,11138 exceeds 1024×768
main: Rect too big

same problem here :
server : 1024 x 768
client : 1680 x 1050
$ vncviewer 192.168.1.150

VNC Viewer Free Edition 4.1.1 for X — built Apr 16 2008 13:23:14
Copyright (C) 2002-2005 RealVNC Ltd.
See http:// www.realvnc. com for information on VNC.

Wed Oct 29 23:03:43 2008
CConn: connected to host 192.168.1.150 port 5900

Wed Oct 29 23:03:45 2008
CConnection: Server supports RFB protocol version 3.3
CConnection: Using RFB protocol version 3.3
.
authorization given for access on server
.
Wed Oct 29 23:03:45 2008
CConnection: Server supports RFB protocol version 3.3
CConnection: Using RFB protocol version 3.3

Wed Oct 29 23:06:04 2008
TXImage: Using default colormap and visual, TrueColor, depth 24.
CConn: Using pixel format depth 6 (8bpp) rgb222
CConn: Using ZRLE encoding
Rect too big: 31349×28192 at 0,0 exceeds 1280×1024
main: Rect too big

Had this exact problem on Gutsy, Hardy, and now Intrepid, using «xvncviewer -ZlibLevel 7 [vnc_display]».

Most of the VNC displays I’m connecting to are Windows 2003 running on Xen (SuSE Linux Enterprise Server 10 SP2). The display sizes range from 640×480 to 800×600. I typically access them through SSH port forwarding, but that may be irrelevant.

Anyway, long story short, I moved over to xtightvncviewer (based on the post I found at http:// ubuntuforums. org/showthread. php?t=695273 ). The problem completely went away, but the speed of the session was abysmally slow (VNC Displays are at a remote data center, accessed through a VPN tunnel). It turned out I needed to specify the encodings. The command that I’m running now is:
xtightvncviewer -compresslevel 7 -encodings «copyrect tight hextile zlib corre rre raw»
I just put that in my .bash_aliases as the command ‘vnc’. So all I need to type is ‘vnc [vnc_display]’.

Works like a charm.

Interesting idea with xtightvncviewer, but I end up getting a similar problem with it too. Here I was connecting to a QEMU session booting OpenSolaris:

]$ xtightvncviewer -compresslevel 7 -encodings «copyrect tight hextile zlib corre rre raw» localhost:1
Connected to RFB server, using protocol version 3.8
No authentication needed
Authentication successful
Desktop name «QEMU»
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
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
Using shared memory PutImage
Rect too large: 720×400 at (0, 0)
ShmCleanup called
[mhicks@ accra][

Well, that’s a different package, and I don’t want to file bugs for that here.

I seem to have the biggest problems in xvnc4viewer when the emulated system is changing video resolution, which happens multiple times in the process of booting a guest. In QEMU or KVM, the resolution also usually changes when accessing the built-in management console by pressing Ctrl+Alt+2 and then change resolution again to go to the emulated VGA by pressing Ctrl+Alt+1.

One potential problem is that xvnc4viewer seems to destroy and re-create a window whenever the resolution changes (well, my compiz window manager thinks it’s doing that anyway — I’m getting the window open/close effects to trigger at these times). I’m suspicious that there may be a timing issue where the client may be trying to draw an image at the new resolution before the window has switched, or in that instant between the old window being destroyed and the new one being created.

Of course, there’s a decent probability that there are bugs in the bulit-in VNC servers on QEMU and KVM, but the client should be more tolerant of bogus data coming down the pipe.

Источник

Describe the bug
I am observing a VNC server crash on client connect after a previously successful connect. This mostly seems to happen if the client disconnects uncleanly, but it is not 100% reproducible. Repeatedly connecting / disconnecting gracefully doesn’t appear to trigger the crash.

VNCserver is hosting a complete XFCE desktop environment along with typical desktop workloads such as Firefox / Thunderbird, etc…

To Reproduce

1. Start the VNC server on the remote host: vncserver -localhost no :1
2. Connect the client: vncviewer server:1
3. Do some work (doesn’t seem to matter how long the connection is open)
4. Close the laptop lid (don’t disconnect gracefully, laptop goes to sleep)
5. Re-connect client: vncviewer server:1
6. Password prompt observed, followed by below mesaage on the client: CConn: End of stream

Expected behavior
VNC server does not crash, and prior session is resumed.

Screenshots

Tue May 19 06:55:44 2020
 Connections: accepted: 10.102.11.143::33660
 SConnection: Client needs protocol version 3.8
 SConnection: Client requests security type VeNCrypt(19)
 SVeNCrypt:   Client requests security type VncAuth (2)
Xtigervnc: /build/tigervnc-vYbVn8/tigervnc-1.10.1+dfsg/common/rfb/VNCServerST.cxx:779: void rfb::VNCServerST::writeUpdate(): Assertion `blockCounter == 0' failed.
(EE)
(EE) Backtrace:
(EE) 0: /usr/bin/Xtigervnc (OsLookupColor+0x13c) [0x55e033ce739c]
(EE) 1: /lib/x86_64-linux-gnu/libpthread.so.0 (funlockfile+0x60) [0x7fa2da16741f]
(EE) 2: /lib/x86_64-linux-gnu/libc.so.6 (gsignal+0xcb) [0x7fa2d96bf18b]
(EE) 3: /lib/x86_64-linux-gnu/libc.so.6 (abort+0x12b) [0x7fa2d969e859]
(EE) unw_get_proc_name failed: no unwind info found [-10]
(EE) 4: /lib/x86_64-linux-gnu/libc.so.6 (?+0x0) [0x7fa2d969e71a]
(EE) 5: /lib/x86_64-linux-gnu/libc.so.6 (__assert_fail+0x46) [0x7fa2d96aff36]
(EE) 6: /usr/bin/Xtigervnc (_ZN3rfb11VNCServerST11writeUpdateEv+0x3cb) [0x55e033c5211b]
(EE) 7: /usr/bin/Xtigervnc (_ZN3rfb11VNCServerST15queryConnectionEPNS_16VNCSConnectionSTEPKc+0x3b) [0x55e033c5244b]
(EE) 8: /usr/bin/Xtigervnc (_ZN3rfb11SConnection18processSecurityMsgEv+0xe8) [0x55e033c58b08]
(EE) 9: /usr/bin/Xtigervnc (_ZN3rfb16VNCSConnectionST15processMessagesEv+0x8e) [0x55e033c64d7e]
(EE) 10: /usr/bin/Xtigervnc (_ZN14XserverDesktop17handleSocketEventEiPN7network12SocketServerEbb+0x99) [0x55e033c426b9]
(EE) 11: /usr/bin/Xtigervnc (_ZN14XserverDesktop17handleSocketEventEibb+0x63) [0x55e033c427a3]
(EE) 12: /usr/bin/Xtigervnc (ospoll_wait+0x81) [0x55e033ce7ce1]
(EE) 13: /usr/bin/Xtigervnc (WaitForSomething+0x193) [0x55e033ce0b13]
(EE) 14: /usr/bin/Xtigervnc (Dispatch+0xab) [0x55e033c9215b]
(EE) 15: /usr/bin/Xtigervnc (dix_main+0x374) [0x55e033c96424]
(EE) 16: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xf3) [0x7fa2d96a00b3]
(EE) 17: /usr/bin/Xtigervnc (_start+0x2e) [0x55e033b61e1e]
(EE)
(EE)
Fatal server error:
(EE) Caught signal 6 (Aborted). Server aborting
(EE)

Client (please complete the following information):
OS: Ubuntu 2004 LTS x86_64

TigerVNC Viewer 64-bit v1.10.1
Built on: 2020-04-09 06:49
Copyright (C) 1999-2019 TigerVNC Team and many others (see README.rst)
See https://www.tigervnc.org for information on TigerVNC.

vncviewer was installed using Ubuntu package manager

Server (please complete the following information):
OS: Ubuntu 2004 LTS x86_64

Linux server 5.4.0-24-generic #28-Ubuntu SMP Thu Apr 9 22:16:42 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Output of vncserver -version

Xvnc TigerVNC 1.10.0 - built Apr  9 2020 06:49:31
Copyright (C) 1999-2019 TigerVNC Team and many others (see README.rst)
See https://www.tigervnc.org for information on TigerVNC.
Underlying X server release 12008000, The X.Org Foundation

vncserver was installed using Ubuntu package manager

Configuration file under ~/.vnc/xstartup:

#!/bin/sh
unset SESSION_MANAGER
unset DBUS_SESSION_BUS_ADDRESS
exec startxfce4

Additional Logs
Below logs show a connection establish Monday May 18 in the morning, disconnect in the evening, reconnect Tuesday May 19 morning followed by crash:

Mon May 18 17:11:37 2020
 Connections: accepted: 10.102.11.143::33456
 SConnection: Client needs protocol version 3.8
 SConnection: Client requests security type VeNCrypt(19)
 SVeNCrypt:   Client requests security type VncAuth (2)

Mon May 18 17:11:51 2020
 VNCSConnST:  Server default pixel format depth 24 (32bpp) little-endian rgb888
 VNCSConnST:  closing 10.102.11.143::32866: Non-shared connection requested
 EncodeManager: Framebuffer updates: 174215
 EncodeManager:   Tight:
 EncodeManager:     Solid: 268.362 krects, 2.4873 Gpixels
 EncodeManager:            4.09488 MiB (1:2317.86 ratio)
 EncodeManager:     Bitmap RLE: 47.952 krects, 69.8018 Mpixels
 EncodeManager:                 1.53744 MiB (1:173.549 ratio)
 EncodeManager:     Indexed RLE: 318.515 krects, 689.35 Mpixels
 EncodeManager:                  60.905 MiB (1:43.2363 ratio)
 EncodeManager:   Tight (JPEG):
 EncodeManager:     Full Colour: 309.413 krects, 2.48831 Gpixels
 EncodeManager:                  1.46426 GiB (1:6.33299 ratio)
 EncodeManager:   Total: 944.242 krects, 5.73476 Gpixels
 EncodeManager:          1.52923 GiB (1:13.9771 ratio)
 Connections: closed: 10.102.11.143::32866
 ComparingUpdateTracker: 173.294 kpixels in / 98.406 kpixels out
 ComparingUpdateTracker: (1:1.76101 ratio)
 ComparingUpdateTracker: 1.738 kpixels in / 1.386 kpixels out
 ComparingUpdateTracker: (1:1.25397 ratio)

.... snip .... Note: laptop lid closed ~few minutes prior to below log line:

Mon May 18 21:53:55 2020
 VNCSConnST:  closing 10.102.11.143::33456: Invalid PixelBuffer height of 21956
              pixels requested
 EncodeManager: Framebuffer updates: 183935
 EncodeManager:   CopyRect:
 EncodeManager:     Copies: 15 rects, 3.47824 Mpixels
 EncodeManager:             294.137 TiB (1:4.30206e-08 ratio)
 EncodeManager:   Tight:
 EncodeManager:     Solid: 460.13 krects, 4.17284 Gpixels
 EncodeManager:            7.02103 MiB (1:2267.96 ratio)
 EncodeManager:     Bitmap RLE: 66.895 krects, 95.3959 Mpixels
 EncodeManager:                 2.24069 MiB (1:162.75 ratio)
 EncodeManager:     Indexed RLE: 440.638 krects, 1.14424 Gpixels
 EncodeManager:                  101.558 MiB (1:43.0293 ratio)
 EncodeManager:   Tight (JPEG):
 EncodeManager:     Full Colour: 490.013 krects, 5.15073 Gpixels
 EncodeManager:                  3.04539 GiB (1:6.30246 ratio)
 EncodeManager:   Total: 1.45769 Mrects, 10.5667 Gpixels
 EncodeManager:          294.14 TiB (1:0.000130745 ratio)
 Connections: closed: 10.102.11.143::33456
 ComparingUpdateTracker: 111.555 Gpixels in / 4.69009 Gpixels out
 ComparingUpdateTracker: (1:23.7853 ratio)

(xfdesktop:352828): Gdk-CRITICAL **: 21:53:58.092: gdk_pixbuf_get_from_surface: assertion 'width > 0 && height > 0' failed

** (xiccd:352872): CRITICAL **: 00:01:09.868: unable to connect to device: Failed to connect to missing device /org/freedesktop/ColorManager/devices/cups_DellC2660dn

** (xiccd:352872): CRITICAL **: 00:01:09.869: unable to connect to device: Failed to connect to missing device /org/freedesktop/ColorManager/devices/cups_DellC2660dn

Tue May 19 06:55:44 2020
 Connections: accepted: 10.102.11.143::33660
 SConnection: Client needs protocol version 3.8
 SConnection: Client requests security type VeNCrypt(19)
 SVeNCrypt:   Client requests security type VncAuth (2)
Xtigervnc: /build/tigervnc-vYbVn8/tigervnc-1.10.1+dfsg/common/rfb/VNCServerST.cxx:779: void rfb::VNCServerST::writeUpdate(): Assertion `blockCounter == 0' failed.
(EE)
(EE) Backtrace:
(EE) 0: /usr/bin/Xtigervnc (OsLookupColor+0x13c) [0x55e033ce739c]
(EE) 1: /lib/x86_64-linux-gnu/libpthread.so.0 (funlockfile+0x60) [0x7fa2da16741f]
(EE) 2: /lib/x86_64-linux-gnu/libc.so.6 (gsignal+0xcb) [0x7fa2d96bf18b]
(EE) 3: /lib/x86_64-linux-gnu/libc.so.6 (abort+0x12b) [0x7fa2d969e859]
(EE) unw_get_proc_name failed: no unwind info found [-10]
(EE) 4: /lib/x86_64-linux-gnu/libc.so.6 (?+0x0) [0x7fa2d969e71a]
(EE) 5: /lib/x86_64-linux-gnu/libc.so.6 (__assert_fail+0x46) [0x7fa2d96aff36]
(EE) 6: /usr/bin/Xtigervnc (_ZN3rfb11VNCServerST11writeUpdateEv+0x3cb) [0x55e033c5211b]
(EE) 7: /usr/bin/Xtigervnc (_ZN3rfb11VNCServerST15queryConnectionEPNS_16VNCSConnectionSTEPKc+0x3b) [0x55e033c5244b]
(EE) 8: /usr/bin/Xtigervnc (_ZN3rfb11SConnection18processSecurityMsgEv+0xe8) [0x55e033c58b08]
(EE) 9: /usr/bin/Xtigervnc (_ZN3rfb16VNCSConnectionST15processMessagesEv+0x8e) [0x55e033c64d7e]
(EE) 10: /usr/bin/Xtigervnc (_ZN14XserverDesktop17handleSocketEventEiPN7network12SocketServerEbb+0x99) [0x55e033c426b9]
(EE) 11: /usr/bin/Xtigervnc (_ZN14XserverDesktop17handleSocketEventEibb+0x63) [0x55e033c427a3]
(EE) 12: /usr/bin/Xtigervnc (ospoll_wait+0x81) [0x55e033ce7ce1]
(EE) 13: /usr/bin/Xtigervnc (WaitForSomething+0x193) [0x55e033ce0b13]
(EE) 14: /usr/bin/Xtigervnc (Dispatch+0xab) [0x55e033c9215b]
(EE) 15: /usr/bin/Xtigervnc (dix_main+0x374) [0x55e033c96424]
(EE) 16: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xf3) [0x7fa2d96a00b3]
(EE) 17: /usr/bin/Xtigervnc (_start+0x2e) [0x55e033b61e1e]
(EE)
(EE)
Fatal server error:
(EE) Caught signal 6 (Aborted). Server aborting
(EE)

Corresponding output on from the client on the connection which caused a crash:

TigerVNC Viewer 64-bit v1.10.1
Built on: 2020-04-09 06:49
Copyright (C) 1999-2019 TigerVNC Team and many others (see README.rst)
See https://www.tigervnc.org for information on TigerVNC.

Tue May 19 06:55:44 2020
 DecodeManager: Detected 4 CPU core(s)
 DecodeManager: Creating 4 decoder thread(s)
 CConn:       Connected to host sever port 5901
 CConnection: Server supports RFB protocol version 3.8
 CConnection: Using RFB protocol version 3.8
 CConnection: Choosing security type VeNCrypt(19)
 CVeNCrypt:   Choosing security type VncAuth (2)

Tue May 19 06:55:48 2020
 CConn:       End of stream