OK, well the image is definitely corrupt, meaning that this is a server-side issue. Is there any way you can try to reproduce the issue using the TurboVNC 2.0 server? Building the TigerVNC Server isn't exactly straightforward, so in order for me to send you an instrumented binary with the afore-mentioned codec checks, I'm going to have to do that using our server code.
It may also be that there is simply a rare bug in the TigerVNC encoder that doesn't affect the TurboVNC Server. On 10/13/15 3:58 PM, Brett Williams wrote: > JPEG image attached. > > On Tue, Oct 13, 2015 at 2:43 PM, DRC <[email protected] > <mailto:[email protected]>> wrote: > > 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]> > <mailto:[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]>> > <mailto:[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]>> > > <mailto:[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]>> > <mailto:[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]>> > <mailto:[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
