Bug 5250 - Impossible to Disconnect Session in some cases
Summary: Impossible to Disconnect Session in some cases
Status: CLOSED WORKSFORME
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Client (show other bugs)
Version: 4.2.0
Hardware: PC Unknown
: P2 Normal
Target Milestone: 4.14.0
Assignee: Linn
URL:
Keywords:
Depends on: 7785
Blocks:
  Show dependency treegraph
 
Reported: 2014-09-10 10:56 CEST by Peter Åstrand
Modified: 2021-12-02 13:52 CET (History)
1 user (show)

See Also:
Acceptance Criteria:


Attachments

Description Peter Åstrand cendio 2014-09-10 10:56:40 CEST
We have at least one report of that in some cases, the action F8 -> Disconnect does not work. In this case, it is possible though to deselect fullscreen, and then disconnect. The details are still a bit unclear, but nevertheless we have found a code path in vncviewer which is not quite right. If we are waiting for more VNC data, the vncviewer will not correctly evaluate the "exitMainloop" variable.
Comment 2 Pierre Ossman cendio 2014-09-22 10:02:51 CEST
Some more details: The theoretical scenario is as follows:

 1. We receive a partial RFB message. The RFB core will then block for more data, and call the block handler in vncviewer.

 2. The block handler calls FLTK's main loop in order to keep the UI running.

 3. Disconnect is selected, or the window is closed. This sets an internal flag to break the primary main loop.

We will now fail to exit as we are currently stuck inside RFB's blocking loop, rather than the top main loop. The UI is still responsive as we keep calling FLTK, but you cannot break the RFB block. The only way out of that is if sufficient data arrives, or the socket throws an error.

So we need to add a way to break the RFB block as well when we are planning to exit. Throwing an exception is one way of getting out of it.
Comment 3 Pierre Ossman cendio 2020-09-29 12:59:39 CEST
I think we have workarounds for this in place already. Need to retest.

This will also definitely be resolved once this PR gets merged:

https://github.com/TigerVNC/tigervnc/pull/1029
Comment 4 Linn cendio 2021-11-30 12:22:46 CET
Was able to reproduce the issue with ThinLinc client 4.2.0 on Fedora 33 and server build 2366 on Ubuntu 20.04.

Scenario
========

1. Log in, run something that will cause lots of graphical updates. I used this video of snow fall: https://www.youtube.com/watch?v=jh_KFTYJnDo

2. Jump to an unbuffered part of the video.

3. Turn off the network on the server. I used ifconfig:
> sudo ifconfig <network> down
4. Go to the client and press F8 -> Disconnect. Nothing should happen.


Note that this scenario only reproduces it sometimes, for me 3 out of 10 times. The other times the client closed when I clicked Disconnect.

Also, step 2 might not be necessary, but I had the most luck when including it and then doing step 3 quite quickly after.
Comment 5 Linn cendio 2021-11-30 13:52:33 CET
Tested with client build 2284 on Fedora 33 and server build 2366 on Ubuntu 20.04.

I tested the scenario from comment 4, and 15 out of 15 tries successfully disconnected. It seems like this issue has been solved.
Comment 6 Linn cendio 2021-11-30 15:22:06 CET
Should also be tested with 4.13.0 to see if it was solved by this fix [1] or if it was fixed before it.

[1]: https://github.com/TigerVNC/tigervnc/pull/1029
Comment 7 Linn cendio 2021-12-01 09:14:57 CET
Also tested the scenario in comment 4 with ThinLinc client 4.13.0 on Fedora 33 and server build 2366 on Ubuntu 20.04. 

15 out of 15 tries successfully disconnected, indicating that this was fixed before our latest upgrade of TigerVNC (bug 7785).
Comment 10 Linn cendio 2021-12-02 13:52:51 CET
This issue was fixed some time between 4.2.0 and 4.13.0.

Note You need to log in before you can comment on or make changes to this bug.