Bug 289 - Remove error dialog after closing client
Summary: Remove error dialog after closing client
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: VNC (show other bugs)
Version: 1.0.1
Hardware: PC Linux
: P2 Normal
Target Milestone: 4.14.0
Assignee: William Sjöblom
Keywords: prosaic, samuel_tester
: 4827 (view as bug list)
Depends on: 7634
  Show dependency treegraph
Reported: 2003-05-09 10:54 CEST by Peter Åstrand
Modified: 2021-11-25 14:08 CET (History)
2 users (show)

See Also:
Acceptance Criteria:
• Network error dialogs from `vncviewer' should be suppressed if these can be reasonably expected to originate from a fault in the SSH tunnel (that will result in an error from `tlclient'). • In case upstream TigerVNC adds additional error conditions, the default behavior shall be to show the error dialog for these as silencing wanted errors is worse than showing unwanted errors.


Description Peter Åstrand cendio 2003-05-09 10:54:00 CEST
When closing the Windows client (normal logout), vncviewer.exe pops up an error
dialog. This is confusing; remove it.
Comment 1 Peter Åstrand cendio 2003-07-10 13:22:04 CEST
This is another reason for building vncviewer.exe and not using the pre-built
version. We could even change strings like "TightVNC viewer" to "ThinLinc
Graphic Session". 
Comment 2 Peter Åstrand cendio 2003-08-28 13:11:39 CEST
Fixed: The dialog is still here, but the exclamation mark has been replaced with
more friendly information sign. 

We are now building vncviewer.exe ourselves, with MinGW. 

Strings with "VNCviewer" and "TightVNC" has been replaced with "ThinLinc viewer". 
Comment 3 Magnus Runesson cendio 2003-09-25 11:14:49 CEST
Says now ThinLinc viewer connection closed. Which is fine.
Comment 4 Peter Åstrand cendio 2003-09-26 14:47:41 CEST
The solution is only partial; sometimes vncviewer says "Error while waiting for
server message", instead. We should probably change this message as well. For 1.3. 
Comment 5 Peter Åstrand cendio 2004-04-16 10:09:32 CEST
Comment 6 Peter Åstrand cendio 2004-11-08 11:35:35 CET
Probably influenced by the VNC4 change. 
Comment 7 Peter Åstrand cendio 2005-02-01 14:26:33 CET
It seems this problem solved itself when switched to vncviewer4. I've not been
able to reproduce it with the new client. 
Comment 8 Erik Forsberg cendio 2005-03-16 14:32:42 CET
No error dialog pops up when closing Windows client.
Comment 9 Peter Åstrand cendio 2005-05-24 15:33:17 CEST
Actually, I've seen this with vncviewer4 as well. I've seen two different error
messages: One with a red cross, and one with a blue "info" symbol. I think this
happened on Windows 95; perhaps the error is only on that platform (which isn't
Comment 10 Peter Åstrand cendio 2005-10-31 13:31:02 CET
This bug should probably be solved by solving bug 1560. 
Comment 11 Pierre Ossman cendio 2011-08-25 14:26:07 CEST
This seems to be solved with our new vncviewer.
Comment 12 Pierre Ossman cendio 2011-11-23 10:37:16 CET
I managed to get a "Connection aborted" from vncviewer on Windows XP when logging out.
Comment 13 Peter Åstrand cendio 2011-11-23 12:56:58 CET
(In reply to comment #12)
> I managed to get a "Connection aborted" from vncviewer on Windows XP when
> logging out.

I've not managed to reproduce this. I've tried, while watching youtube:

* killing tlssh.exe

* pulling the network cable

* killing Xvnc with -9

* killing sshd

I'm somewhat out of ideas. Moving forward, I think we need to collect more data of when this is happening. 
Comment 14 Karl Mikaelsson cendio 2012-12-06 14:53:04 CET
I've seen it happen on the Windows 8 machine in the lab.
Comment 15 Peter Åstrand cendio 2013-10-07 13:43:11 CEST
*** Bug 4827 has been marked as a duplicate of this bug. ***
Comment 16 Karl Mikaelsson cendio 2018-03-13 18:19:27 CET
I saw this happen today with a (32-bit) 4.8.0 client on Windows 10.

> +----------------------------------------+
> | ThinLinc-klient                        |
> +----------------------------------------+
> |+---+  read: Connection aborted (10053) |
> || ! |                                   |
> |+---+                           [Stäng] |
> +----------------------------------------+
Comment 17 Karl Mikaelsson cendio 2018-03-13 18:22:32 CET
(In reply to comment #16)
Last lines in tlclient.log:

> 2018-03-13T17:47:23: vncviewer[E]: Tue Mar 13 17:47:23 2018
> 2018-03-13T17:47:23: vncviewer[E]:  CConn:       Använder kodning Tight
> 2018-03-13T17:47:23: vncviewer[E]:  CConn:       Bandbredd 16380 kbit/s - byter till kvalitet 8
> 2018-03-13T17:47:23: vncviewer[E]:  CConn:       Använder kodning Tight
> 2018-03-13T18:15:50: vncviewer[E]: 
> 2018-03-13T18:15:50: vncviewer[E]: Tue Mar 13 18:15:50 2018
> 2018-03-13T18:15:50: vncviewer[E]:  CConn:       read: Connection aborted (10053)
> 2018-03-13T18:19:34: WinProcess: Process 9964 (ssh.exe) did not exit in a timely manner. Forcing termination...
> 2018-03-13T18:19:36: WinProcess: Process 3828 (pcsctun.exe) did not exit in a timely manner. Forcing termination...
> 2018-03-13T18:19:36: Log file ended

Note the timestamps between the CConn line and the WinProcess line. What's going on here...
Comment 18 Samuel Mannehed cendio 2018-03-20 14:30:20 CET
I got a "broken pipe" error today when connecting using a Fedora 27 client to a Ubuntu 16.04 server:

> +----------------------------------------+
> | ThinLinc-klient                        |
> +----------------------------------------+
> |+---+  write: Brutet rör (32)           |
> || ! |                                   |
> |+---+                           [Stäng] |
> +----------------------------------------+

It seems the issue isn't limited to the Windows client. I don't know if it matters, but I ran the client through valgrind when it happened.

This is what the tlclient.log says:

> 2018-03-20T13:59:21: vncviewer[E]: Tue Mar 20 13:59:21 2018
> 2018-03-20T13:59:21: vncviewer[E]:  CConn:       Använder pixelformat depth 24 (32bpp) little-endian rgb888
> 2018-03-20T13:59:21: vncviewer[E]:  CConn:       Använder kodning Tight
> 2018-03-20T13:59:21: vncviewer[E]:  CConn:       Aktiverar kontinuerliga uppdateringar
> 2018-03-20T13:59:22: vncviewer[E]: 
> 2018-03-20T13:59:22: vncviewer[E]: Tue Mar 20 13:59:22 2018
> 2018-03-20T13:59:22: vncviewer[E]:  CConn:       write: Brutet rör (32)
> 2018-03-20T13:59:22: vncviewer[E]: Fontconfig error: "/etc/fonts/conf.d/10-scale-bitmap-fonts.conf", line 72: non-double matrix element
> 2018-03-20T13:59:22: Last line was repeated 1 time(s).
> 2018-03-20T13:59:22: vncviewer[E]: Fontconfig warning: "/etc/fonts/conf.d/10-scale-bitmap-fonts.conf", line 80: saw unknown, expected number
Comment 19 Samuel Mannehed cendio 2018-10-29 12:24:01 CET
I got the same error as in comment #16 when logging out using the 4.9.0post client build 5942 on Windows 10.

(In reply to comment #17)
> Note the timestamps between the CConn line and the WinProcess line. What's
> going on here...

The WinProcess lines are printed when the last child process dies, that is when you close the error dialogue.
Comment 21 Pierre Ossman cendio 2021-09-28 09:42:40 CEST
EPIPE is handled on bug 1560, so this bug is about ECONNABORTED.

This error code seems to be used for some internal corner cases in the TCP stack, so it is extremely rarely seen. Which explains why it is so very hard to reproduce. These links discuss a bit about when this can happen for Windows and Linux respectively:


In the end though it is not much different from ECONNRESET, which we silenced in bug 3885. We should probably improve upon that fix and silence all network errors in vncviewer since they are not relevant (ssh is the process with the "real" network connection). That would likely also fix bug 1560.
Comment 22 William Sjöblom cendio 2021-11-19 10:17:32 CET
To fix these (this and bug 1560) error dialogs once and for all I've
mapped out all possible error dialogs from vncviewer. To polish the fix
in bug 3885 and suppress the additional network error dialogs, we want a
clear view of which of the full range of error dialogs to suppress.

Errors shown by vncviewer:
• Socket errors
  • "Failure waiting for incoming VNC connections" (vncviewer.cxx)
  • Clipboard communication failures (Viewport.cxx)
  • Pointer communication failures (Viewport.cxx)
  • Key communication failures (Viewport.cxx)
  • "Failed to connect" (CConn.cxx)
  • "Connection was dropped by the sever before the session could be
    established" (CConn.cxx)
  • "An unexpected error occurred when communicating with the server"
• Touch errors
  • Windows: "Failed to create touch handler" (touch.cxx)
  • Linux: "X Input extension not available" (touch.cxx)
  • Linux: "X Input 2 (or newer) is not available" (touch.cxx)
• Configuration errors
  • "Unable to load the specified configuration" (vncviewer.cxx)
  • "Parameters -listen and -via are incompatible" (vncviewer.cxx)

These are my conclusions from the above errors:
• We want to keep the touch errors since these would be really annoying
  to catch in tlclient.
• Configuration errors should not happen since tlclient is in control of
  the vncviewer configuration, so if these are kept or suppressed
  doesn't really matter. Nonetheless, we should probably keep these in
  to minimize the diff compared to upstream TigerVNC.
• Socket errors are likely to all be related to problems with the
  ssh-tunnel and, if that proves to be the case, can all be
  suppressed. This needs some further investigation.
Comment 23 William Sjöblom cendio 2021-11-19 15:46:02 CET
After some investigation into the different errno's we risk running in
to, it seems reasonable to assume that errno's returned by socket calls
will all be caught by the SSH tunnel. This is, of course, an assumption
which is about as good as it gets since these errors are typically hard
to reproduce.

What remains now is to figure out a way to selectively ignore socket
errors from the rest of the exceptions, that is both prettier than the
current way of ignoring ECONNRESETS and that does not mess up the 
upstream diff too much.
Comment 26 William Sjöblom cendio 2021-11-23 14:41:43 CET
The fix included some refactoring suitable for upstreaming (see
https://github.com/TigerVNC/tigervnc/commit/15caddf67b). This resulted
in another vendordrop of TigerVNC instead of a cherry-pick since no
other changes to TigerVNC were introduced between the last vendor drop
and this commit.

Since these error conditions tend to be somewhat temperamental, my
testing has mainly consisted of retesting bug 3885 (making sure that the
error dialog is still suppressed since my fix replace the previous fix
for bug 3885) as well as artificially throwing "silenced" and
"non-silenced" exceptions to make sure that the suppression logic works
as intended. I have also verified that the error dialogs in this bug
and bug 1560 originate from these, now "silenced", exceptions.
Comment 27 William Sjöblom cendio 2021-11-24 08:52:33 CET
A build has now been completed with the changes in place. Marking as resolved.
Comment 29 Samuel Mannehed cendio 2021-11-25 14:08:34 CET
These problems are a bit elusive which makes them hard to properly verify. I have used client build 2278 on Windows 10 and Fedora 34 to test a number of different ways to exit the client:

 * vncconfig -disconnect

   No error dialog
   "CConn: End of stream" in log

 * Pulling the smart card used for authentication

   No error dialog
   "CConn: read: An existing connection was forcibly closed by the remote host" in log

 * ​killing the Xvnc process

   No error dialog
   "CConn: End of stream" in log

 ​* blocking the traffic on the vncviewer port using iptables

   No error dialog
   "CConn: read: Connection refused (111)" in log

 * killing the ssh process

   "Connection was unexpectedly shut down.." dialog
   "The SSH process unexpectedly exited before VNC viewer process." in log

The client behaves as expected. I have also reviewed the code changes and they look good.

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