Thanks for the easy shortcut: >> LD_LIBRARY_PATH=/opt/libjpeg-turbo/lib64:$LD_LIBRARY_PATH ldd `which Xvnc` | grep jpeg libjpeg.so.62 => /opt/libjpeg-turbo/lib64/libjpeg.so.62 (0x00007f3325a15000) >> LD_LIBRARY_PATH=/opt/libjpeg-turbo/lib64:$LD_LIBRARY_PATH vncserver -geometry 3840x1080
Upon connecting and starting the tool with some basic operations, I get the corrupted jpeg. The good news this is seems to be easier to reproduce than I originally imagined. On Tue, Oct 13, 2015 at 12:40 PM, DRC <[email protected]> wrote: > 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
