TurboVNC / turbovnc

Main TurboVNC repository
https://TurboVNC.org
GNU General Public License v2.0
761 stars 138 forks source link

Windows vncviewer hanging #280

Closed wqweto closed 3 years ago

wqweto commented 3 years ago

The 32-bit windows client works on my desktop but hangs on an ancient laptop with i5-2557M (with Win10 x86) just after auth before showing initial remote screen.

Here is the CPU in question

image

Couldn't find minimum CPU requirements on libjpeg-turbo (or this issue might have nothing to do with the CPU).

dcommander commented 3 years ago

Which version of the 32-bit Windows TurboVNC Viewer are you using? Which version of the TurboVNC Server are you connecting to? The CPU isn't the issue. Please re-run the viewer from the command line using

c:\program files\turbovnc\cvncviewer /loglevel 8

and post the output.

wqweto commented 3 years ago

First I tried https://sourceforge.net/projects/turbovnc/files/2.2.6/TurboVNC-2.2.6-x86.exe/download but then downgraded to https://sourceforge.net/projects/turbovnc/files/2.2/TurboVNC-2.2.exe/download

Here is the log from the laptop hanging

C:\Program Files\TurboVNC>cvncviewer.exe /loglevel 8 /logfile c:\temp\vnc.log
Started and Winsock (v 2) initialised
WinTab library not available
Buffer size expanded to 4352
Registered connection with app
Connected to ****.COM port 4402
RFB server supports protocol version 3.8
Connected to RFB server, using protocol version 3.8
Enabling TightVNC protocol extensions
No authentication needed
Authentication scheme: No authentication
Authentication successful
Clipboard changed
Don't send initial clipboard!
Desktop name "VbVncServer"
Geometry 2560 x 1440 depth 24
Screen 0 work area: 0, 0 2048 x 1112

C:\Program Files\TurboVNC>

Here is the same log from the desktop working ok

C:\Program Files (x86)\TurboVNC>cvncviewer.exe /loglevel 8 /logfile c:\temp\vnc.log
Started and Winsock (v 2) initialised
WinTab library not available
Buffer size expanded to 4352
Registered connection with app
Connected to ***.com port 4402
RFB server supports protocol version 3.8
Connected to RFB server, using protocol version 3.8
Enabling TightVNC protocol extensions
No authentication needed
Authentication scheme: No authentication
Authentication successful
Clipboard changed
Don't send initial clipboard!
Desktop name "VbVncServer"
Geometry 2560 x 1440 depth 24
Screen 0 work area: 0, 0 2048 x 1112
Screen 1 work area: -1920, 0 1920 x 1040
Receiving cursor shape update, cursor 32x32
Buffer size expanded to 11212
Buffer size expanded to 11517
Buffer size expanded to 12156
Buffer size expanded to 12907
Receiving cursor shape update, cursor 32x32
Receiving cursor shape update, cursor 32x32
Buffer size expanded to 14829
Receiving cursor shape update, cursor 32x32
Receiving cursor shape update, cursor 32x32
Receiving cursor shape update, cursor 32x32
Receiving cursor shape update, cursor 32x32
Receiving cursor shape update, cursor 32x32
Receiving cursor shape update, cursor 32x32
Receiving cursor shape update, cursor 32x32
Receiving cursor shape update, cursor 32x32
Receiving cursor shape update, cursor 32x32
Receiving cursor shape update, cursor 32x32
Receiving cursor shape update, cursor 32x32
Receiving cursor shape update, cursor 32x32
Receiving cursor shape update, cursor 32x32
Receiving cursor shape update, cursor 32x32
Receiving cursor shape update, cursor 32x32
Receiving cursor shape update, cursor 32x32
Receiving cursor shape update, cursor 32x32
Receiving cursor shape update, cursor 32x32
Receiving cursor shape update, cursor 32x32
Receiving cursor shape update, cursor 32x32
Receiving cursor shape update, cursor 32x32
Buffer size expanded to 17066
Buffer size expanded to 17885
Buffer size expanded to 26920
Buffer size expanded to 27420
Buffer size expanded to 28196
Buffer size expanded to 30212
Buffer size expanded to 35604
Receiving cursor shape update, cursor 32x32
Receiving cursor shape update, cursor 32x32
Receiving cursor shape update, cursor 32x32
Receiving cursor shape update, cursor 32x32
Buffer size expanded to 35875
Buffer size expanded to 38029
Buffer size expanded to 42570
Receiving cursor shape update, cursor 32x32
Socket error reading message: 10004
Deregistered connection from app
Exiting
VNC viewer closing down

C:\Program Files (x86)\TurboVNC>

I'm testing this against a VNC server of mine but will have to try it against TurboVNC own server to be sure it's not server issue -- possible but pretty unlikely if the client on the desktop works very well.

dcommander commented 3 years ago

I can imagine several scenarios in which a VNC server bug could cause this. Please verify whether the issue exists with the TurboVNC Server.

dcommander commented 3 years ago

Since you control the server code, I would also suggest examining both the client and server and figuring out exactly where the hangup occurs. That will help me to understand the problem and determine whether it is best addressed in our code or yours.

wqweto commented 3 years ago

Just tested with TighVNC server (v2.8.59) and it's crashing the same way

C:\Program Files\TurboVNC>cvncviewer.exe /loglevel 8
Started and Winsock (v 2) initialised
WinTab library not available
Buffer size expanded to 4352
Registered connection with app
Connected to FREE.BGBIZ.COM port 4402
RFB server supports protocol version 3.8
Connected to RFB server, using protocol version 3.8
Enabling TightVNC protocol extensions
Authentication scheme: Standard VNC authentication
Authentication successful
Clipboard changed
Don't send initial clipboard!
Desktop name "wqw-pc"
Geometry 4960 x 1440 depth 24
Screen 0 work area: 0, 0 2048 x 1112

Is it possible to somehow test if libjpeg-turbo is working on my CPU at all? Is there some simple conversion tool as a test project that I cannot find on sourceforge?

As far as I can see the trace in my server, the session gets to client messages and I get SetPixelFormat (0) and SetEncodings (2) but never reach to FramebufferUpdateRequest (3). Here is the data received

image

dcommander commented 3 years ago

Yes, you can download the 32-bit libjpeg-turbo SDK for Windows. This is the one that I used to build the 2.2.6 TurboVNC Viewer: https://sourceforge.net/projects/libjpeg-turbo/files/2.0.6/libjpeg-turbo-2.0.6-vc.exe/download

From a command prompt, run

c:\libjpeg-turbo\bin\tjbench.exe

and pass any JPEG image to it on the command line. That will exactly simulate the usage of libjpeg-turbo by the TurboVNC Viewer, using the same API calls.

wqweto commented 3 years ago
C:\TEMP>tjbench.exe aaa.jpg

>>>>>  JPEG 4:2:0 --> BGR (Top-down)  <<<<<

Image size: 2560 x 1440
Decompress    --> Frame rate:         51.947724 fps
                  Throughput:         191.500090 Megapixels/sec

Yes, this works so probably not the CPU and no problem with libjpeg-turbo per se. Sounds logical as the client just fails before using JPEG decompression at all, before receiving any Tight encoded framebuffer.

Thought it was DirectX initialization (no idea if TurboVNC uses DX or GDI for the client window) so changed the screen resolution both on the client and the server but this did not have any effect. I'm out of ideas and will probably leave this as unresolved mystery.

Thanks for the support and feedback!

dcommander commented 3 years ago

Can you please test it with the TurboVNC Server? That is an important data point.

I'm suspicious that the issue is somehow related to the RFB extended desktop size extension, because comparing your two logs above, the viewer appears to hang up after receiving the first virtual screen but before receiving the second.

I can tell you that the viewer uses GDI, not DX.

wqweto commented 3 years ago

Can you please test it with the TurboVNC Server? That is an important data point.

I would but I don't see the Windows port of the server on sourceforge.

dcommander commented 3 years ago

The TurboVNC Server is Un*x-only.

dcommander commented 3 years ago

I spun a 32-bit build of the latest 2.2.x code and ran it on Windows XP, which is about as ancient as I can muster (on a fairly recent CPU, though), and it works fine when connecting to your VNC server. So I'm stumped as to what could be causing this. If you discover anything new, please update the issue, but I'm closing it for now.