"Rect too big" in TurboVNC 3.0

[Felix Natter]

hello TurboVNC community,

as soon as I start xfreerdp, TurboVNC crashes with the following message:

CMsgReader: Rect too big: 32768x1 at 63488,0 exceeds 3840x1080

Is there a solution or workaround? I could not reproduce it with

the beta.

Many Thanks and Best Regards,

Felix

[DRC]

Please clarify what you mean by “start xfreerdp”. Are you trying to launch xfreerdp within the TurboVNC session and connect to an RDP host? What is the geometry/resolution of the TurboVNC session and the RDP host?

This is the first I have heard about the issue, so I need to be able to reproduce it before I can fix it.

On Jul 27, 2022, at 2:32 AM, Felix Natter <felix....@sidact.com> wrote:



--
You received this message because you are subscribed to the Google Groups "TurboVNC User Discussion/Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to turbovnc-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-users/08ff38fd-813b-423a-a484-7f1d03528225n%40googlegroups.com.

[Felix Natter]

hello DRC,

thank you for your answer. Yes, I am running xfreerdp from the TurboVNC session. I tried again (it does not occur on all windows machines):

CMsgReader: Rect too big: 32768x1 at 63488,0 exceeds 1240x900

TVNC resolution when starting xfreerdp: 1240x900. When I successfully login via rdp (outside of the vnc session),

it gets 1920x1080 (the resolution of one of two monitors). I do not know the resolution it gets under turbovnc,

because it makes turbovnc crash.

I am using freerdp-2.0.0-rc4 like this:

xfree() {
  $MYXFREERDP /sound:sys:pulse /microphone:sys:pulse +clipboard /u:$USERNAME /monitors:1 /multimon -sec-nla /v:$1
}

I tried adding /w:800 and /h:600 but it still crashes.

Many Thanks and Best Regards,.

Felix

[Felix Natter]

It is also reproducible with 2.2.91-20220317.

[DRC]

Nothing changed between 3.0 beta1 and the 20220317 build that would explain this.  I will try to reproduce it.

DRC

To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-users/1e370764-5c0d-4e10-bb4d-0628fc0d89een%40googlegroups.com.

[Felix Natter]

hello DRC,

I must correct this: I was able to reproduce this with a 2.2.91-20220317 client and a 3.0 server.

I am not sure about previous versions, or client=2.2.91 with server=2.2.91.

Also I think it crashes only after you logged in to RDP.

Many Thanks!

Best Regards,

Felix

[DRC]

Unfortunately I can't reproduce the issue.  Are you using any non-default settings?

--
You received this message because you are subscribed to the Google Groups "TurboVNC User Discussion/Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to turbovnc-user...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-users/c552b541-ee84-41e2-9aed-260d157edbdbn%40googlegroups.com.

[Felix Natter]

hallo DRC,

I am using /opt/TurboVNC/bin/vncviewer -Toolbar=0 -Shared=0 -MenuKey=F2 -Encoding=Tight -JPEG=1 -Quality=70 -CompressLevel=7 -Subsampling=4x X:1

but I can reproduce it without all those settings. Another user using the same TurboVNC version (3.0) does not have any problems.

Are there any persistent settings (I did not change anything in ~/.vnc)?

Also, it works with Windows VMs (which can supposedly adapt their resolution). Setting TVNC to fullscreen before running xfreerdp

helped once, but now it crashes in this case, too.

Many Thanks and Best Regards,

Felix Natter

[DRC]

Are you using ALR or any non-default server settings?  I don't understand your comment about adaptive resolutions.  Remote Desktop should always adapt the resolution, and what I observe is that, after connecting to Windows, the remote desktop is the same size as the TurboVNC session.  This is true regardless of whether I connect to a Windows VM or a physical Windows machine.

Generally speaking, a "Rect too big" error is caused by a protocol mismatch.  The error could happen if the server sends an RFB message that the viewer cannot handle, which is why the server and viewer negotiate their capabilities beforehand.  The error could also happen due to data corruption on the network, which could be the result of a faulty firewall or other intermediary.  In order to diagnose the issue, I would first need to reliably reproduce it.  Then I would insert a lot of logging statements into the server to determine exactly what it is trying to send whenever the error occurs.

Since I can't repro the issue, it would be a useful datapoint to determine whether it occurs with a different VNC viewer, such as the TigerVNC Viewer.

[Felix Natter]

hello DRC,

no, I am just using "/opt/TurboVNC/bin/vncserver :1". Yes, my comment about adaptive resolutions is wrong :-/

TurboVNC 3.0 Server with TigerVNC-Viewer (64-bit) Version 1.8.0 does not show this problem.

It is unlikely a network/firewall problem because for another user it works fine between the same two computers.

Thanks and Best Regards,

Felix

[DRC]

So you're saying that when another user logs into the same client and uses the same installation of the TurboVNC Viewer, they do not observe the issue?  IOW, the issue is specific to your user account on that machine?

--

You received this message because you are subscribed to the Google Groups "TurboVNC User Discussion/Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to turbovnc-user...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-users/b263a77f-d4a0-49f6-8b18-288ededf9ecan%40googlegroups.com.

[Felix Natter]

hello DRC,

Yes, it looks like it.

Best Regards,

Felix

[DRC]

That is really weird.  Is this a Linux client?  If so, then try removing the ~/.java directory under your user account.  That will ensure that the viewer is working from a clean slate.  If that doesn't help, then try removing ~/.cache.  Also make a note of the Java version in the TurboVNC Viewer's "About" dialog and make sure that the same version is displayed when the viewer is run under the other user's account.  Unfortunately, those are the only ideas I have, and to be clear, I am grasping at straws.  I have never observed anything like this before.

[Felix Natter]

hello DRC,

yes, it is a Linux (Scientific Linux 7 ~= Redhat7) client (and server). Renaming ~/.java and ~/.cache does not help.

However, I do have a workaround with the tigervnc viewer which seems to work fine (but I have to test some more).

Thanks for your help (and let me know if you have further ideas)!

Best Regards,

Felix

[DRC]

If I could reproduce the issue, then I am confident that I could diagnose it.  Barring that, however, the only other suggestion I have would be to carefully examine differences between your user account and the account of the user who can use TurboVNC successfully.  I assume that the user who can use TurboVNC successfully is connecting to a different TurboVNC Server session, so perhaps the difference that matters is on the server side, not the client side.

DRC

--

You received this message because you are subscribed to the Google Groups "TurboVNC User Discussion/Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to turbovnc-user...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-users/bcae8869-8292-4c25-a435-b1cc42b64397n%40googlegroups.com.