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]> 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]> > 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] >> https://lists.sourceforge.net/lists/listinfo/turbovnc-users >> >> >
------------------------------------------------------------------------------
_______________________________________________ TurboVNC-Users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/turbovnc-users
