Comment 1 Peter Åstrand 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 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 2003-09-25 11:14:49 CEST

Says now ThinLinc viewer connection closed. Which is fine.

Comment 4 Peter Åstrand 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 2004-04-16 10:09:32 CEST

Re-targeting. 

Comment 6 Peter Åstrand 2004-11-08 11:35:35 CET

Probably influenced by the VNC4 change. 

Comment 7 Peter Åstrand 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 2005-03-16 14:32:42 CET

No error dialog pops up when closing Windows client.

Comment 9 Peter Åstrand 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
supported). 

Comment 10 Peter Åstrand 2005-10-31 13:31:02 CET

This bug should probably be solved by solving bug 1560. 

Comment 11 Pierre Ossman 2011-08-25 14:26:07 CEST

This seems to be solved with our new vncviewer.

Comment 12 Pierre Ossman 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 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 2012-12-06 14:53:04 CET

I've seen it happen on the Windows 8 machine in the lab.

Comment 15 Peter Åstrand 2013-10-07 13:43:11 CEST

*** Bug 4827 has been marked as a duplicate of this bug. ***

Comment 16 Karl Mikaelsson 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 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 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 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 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:

https://www.chilkatsoft.com/p/p_299.asp
https://stackoverflow.com/questions/9646550/what-does-econnaborted-mean-when-trying-to-connect-a-socket

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 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"
    (CConn.cxx)
• 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 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 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 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 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.