I understand that these sorts of errors are annoying, but they're also 
extremely rare, which is why I want them to be caught and reported.  If 
I make the viewer "tolerate" such errors, then users will never report 
them, and they'll never get fixed.

Other VNC viewers may not have the issue because they aren't using JPEG 
encoding (RealVNC, for instance, doesn't support JPEG) or, for whatever 
reason, they aren't triggering the same image sequence on the server.

In any sense, this is a serious and rare bug.  It's something that needs 
to be fixed ASAP.

The BUILDING.txt document explains everything you need to know about 
building the Mac Java viewer.  I think all you'll need is just the Apple 
Java development package and CMake.


On 10/13/15 12:20 PM, Brett Williams wrote:
> It took only a few minutes to see that updating the server did not solve
> this issue.  I'll try applying the patch, but unfortunately am not
> experienced building things for the mac (the mac is just a glorified
> window into  linux machines, with which I am much more comfortable).
>
> So it will take some time for me to get this figured out.  The
> buildscript doesn't look complex though and the patch is simple so I'll
> take a stab.
>
> Is there any possibility that the client could be made tolerant of this
> kind of error?  Other VNC clients do not seem to have this issue.  (that
> said they have other issues which is why turbovnc is my #1 choice right
> now if I can resolve this issue :)
>
> On Tue, Oct 13, 2015 at 10:44 AM, Brett Williams <[email protected]
> <mailto:[email protected]>> wrote:
>
>     Thank you for your response.
>
>     I am now running tigervnc 1.5.0 (the latest release) for the
>     server.  The production version of this deployment will have this
>     latest version (my particular setup did not).
>
>     If this issue doesn't occur after a few days of working with the
>     application using the newer version of the tigervnc server, that
>     should be sufficient confirmation that it fixes the issue.  If the
>     issue reoccurs I will try your patch.
>
>     This also required an update of the pixmap package on the server side.
>
>     On Mon, Oct 12, 2015 at 11:49 PM, DRC
>     <[email protected]
>     <mailto:[email protected]>> wrote:
>
>         w/ attachment
>
>
>         On 10/13/15 12:22 AM, DRC wrote:
>
>             I very strongly suspect that this issue is on the server
>             side, and I
>             think it's probably due to an issue in libjpeg-turbo that
>             has long since
>             been fixed.  TigerVNC 1.3.0 is quite old, and perhaps you're
>             using a
>             binary of it that was statically linked against an older
>             version of
>             libjpeg-turbo-- if you're using the "official" TigerVNC
>             binary for
>             1.3.0, then it was probably linked against libjpeg-turbo
>             1.3.0.  There
>             have been several fixes to libjpeg-turbo since then that
>             could account
>             for this error.
>
>             My most immediate suggestion would be to either switch to
>             the TurboVNC
>             2.0 Server or upgrade to a newer build of TigerVNC and see
>             if that
>             eliminates the issue.  If not, then you can apply the
>             attached patch to
>             save the JPEG file that is causing the error (it should be
>             called
>             "error0.jpg".)  Hopefully I can at least verify whether the
>             erroneous
>             JPEG is exhibiting one of the known bugs in past versions of
>             libjpeg-turbo or whether this is a new bug.  If none of
>             those diagnostic
>             techniques produces the desired result, then we may need to
>             get more
>             creative.
>
>
>             On 10/9/15 8:55 AM, Brett Williams wrote:
>
>                 There is one application that I use which frequently
>                 will crash TurboVNC
>                 viewer.
>
>                 I've attached an image of the error message.  Because
>                 this error message
>                 disconnects the viewer, and a subsequent reconnect
>                 immediately has the
>                 same problem, my only workaround is to use a different
>                 VNC viewer to
>                 connect and change the state a bit.  Then I can
>                 reconnect using TurboVNC.
>
>                 However, the problem will reoccur a few times a day.
>
>                 I am unsure how to create a useful test case for this
>                 situation.  Is
>                 there some kind of debug informational dump that I could
>                 do?  The
>                 application in question is commercial software.
>
>                 Client:
>                 Mac OS/X 10.9.5
>                 TurboVNC Viewer 2.0 (20150714) (Java Hotspot 1.6.0_65
>                 x86_64)
>
>                 Server:
>                 CentOS 6.4
>                 tigerVNC 1.3.0-16
>
>
>         
> ------------------------------------------------------------------------------
>
>         _______________________________________________
>         TurboVNC-Users mailing list
>         [email protected]
>         <mailto:[email protected]>
>         https://lists.sourceforge.net/lists/listinfo/turbovnc-users
>
>
>
>
>
> ------------------------------------------------------------------------------
>
>
>
> _______________________________________________
> TurboVNC-Users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/turbovnc-users
>

------------------------------------------------------------------------------
_______________________________________________
TurboVNC-Users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/turbovnc-users

Reply via email to