Connecting to osxvnc server occasionally fails even when CotVNC works

[GoogleCodeExporter]

Sometimes trying to connect to my test server himiko will fail and the app with 
exit immediately, 
before any part of the remote display is drawn. This state will persist until 
the server is rebooted. 
And even though vnsea has problems, cotvnc connecting to the same server works 
just fine.

Original issue reported on code.google.com by crf...@gmail.com on 7 Oct 2007 at 10:34

[GoogleCodeExporter]

The specific failure symptom is that vnsea doesn't make it past the 
setEncodings: method of RFBProtocol. It 
sends the 4 header bytes for that message and then exits. Note that it doesn't 
actually crash, so exit(3) must be 
called somehow.

Original comment by crf...@gmail.com on 7 Oct 2007 at 10:41

[GoogleCodeExporter]

This seems to be the same as issue 31. Turning on the shared setting makes the 
problem go away for some 
reason.

Original comment by crf...@gmail.com on 7 Oct 2007 at 11:31

[GoogleCodeExporter]

The real issue here is that the server has become confused and thinks that a 
client is still connected. Probably 
due to an abnormal disconnection. So when the client connects and sends the 
byte that signals non-shared 
mode, the server immediately disconnects. For some reason, vnsea doesn't handle 
this disconnection and dies 
when it tries to send data to a dead socket.

Of course, that explains why it works fine when you turn on the shared switch.

Original comment by crf...@gmail.com on 12 Oct 2007 at 3:27

[GoogleCodeExporter]

Resolved in svn revision 21.

The ultimate problem here was that when the server closed the connection (see 
above in comment 3 for why), 
the app received a SIGPIPE signal. The default handler for SIGPIPE simply 
terminates the process, explaining 
the resulting defect. To fix it, all that was needed was to set SIGPIPE to be 
ignored.

A side issue also fixed in revision 21 was that the app would abort upon a 
closed connection. The problem 
was that it would process the termination and dispose of objects that were 
still in the call stack. A better 
solution is still needed for this, and ties in with issue 49. Cotvnc should 
have the same problem, so I'm 
surprised it doesn't crash when the server closes the connection. Must be sheer 
luck.

Original comment by crf...@gmail.com on 15 Oct 2007 at 1:05

• Changed state: Fixed

[GoogleCodeExporter]

Original comment by crf...@gmail.com on 15 Oct 2007 at 6:34

• Changed state: Verified