Send me the JPEG image, if you can. If I can make the decoding of the image fail using stand-alone libjpeg-turbo, then we know that it's an encoder bug (i.e. the image is genuinely corrupt), and my next step will be to send you a patch against the server that tests the decoding of each JPEG image prior to sending it and stores the unencoded image if an error is encountered in the JPEG codec.
On 10/13/15 2:36 PM, Brett Williams wrote: > 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] > <mailto:[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]> > <mailto:[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]> > <mailto:[email protected] > <mailto:[email protected]>> > https://lists.sourceforge.net/lists/listinfo/turbovnc-users > > > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > TurboVNC-Users mailing list > [email protected] > <mailto:[email protected]> > <mailto:[email protected] > <mailto:[email protected]>> > https://lists.sourceforge.net/lists/listinfo/turbovnc-users > > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > TurboVNC-Users mailing list > [email protected] > <mailto:[email protected]> > <mailto:[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
