Brian, I actually updated my machine to CentOS 6.5, and the version I have is: libjpeg-turbo-1.2.1-1.el6.x86_64
Naming conventions suggest that with only the release number being updated that the code used isn't different for libjpeg turbo. Do you think there is a reasonable chance that the -3 release is compiled differently enough to make it relevant in this situation? If you think so, I will try to update that package. Unfortunately the box I'm using is the box I have to use for day-to-day work (which is why it isn't 6.7 since I'd be the first to go there). So there'll be a natural limit to my tolerance for updating further :) On Tue, Oct 13, 2015 at 11:30 AM, Brian Hinz <[email protected]> wrote: > On CentOS 6, TigerVNC's official builds are linked against the system > supplied version of libjpeg-turbo, not a statically built copy. At least > on my fully up to date CentOS 6.7 box, this corresponds to > libjpeg-turbo-1.2.1-3.el6_5. > > -brian > > On Tue, Oct 13, 2015 at 1: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 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 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 >> >> > > > ------------------------------------------------------------------------------ > > _______________________________________________ > 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
