Since your build of the TigerVNC Server is dynamically linking with libjpeg-turbo, there's an easy way to make it use a newer libjpeg-turbo release. Download the official libjpeg-turbo 1.4.2 RPM from https://sourceforge.net/projects/libjpeg-turbo/files/1.4.2/. It will install under /opt/libjpeg-turbo, so it shouldn't interfere with the existing 1.2.1 RPM. Now you can do
LD_LIBRARY_PATH=/opt/libjpeg-turbo/lib64:$LD_LIBRARY_PATH vncserver to start the TigerVNC Server using the newer libjpeg-turbo build (as a sanity check, you might want to do LD_LIBRARY_PATH=/opt/libjpeg-turbo/lib64:$LD_LIBRARY_PATH ldd `which Xvnc` to verify that it's picking up the correct version of libjpeg.so.62 (under /opt/libjpeg-turbo.) I don't think upgrading to libjpeg-turbo-1.2.1-3 is going to make any difference. The libjpeg-turbo bug fixes that I most suspect are responsible for this were all introduced in libjpeg-turbo 1.3 and later. On 10/13/15 12:44 PM, Brett Williams wrote: > 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] <mailto:[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] > <mailto:[email protected]> > https://lists.sourceforge.net/lists/listinfo/turbovnc-users > > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > TurboVNC-Users mailing list > [email protected] > <mailto:[email protected]> > https://lists.sourceforge.net/lists/listinfo/turbovnc-users > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > 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
