I've been unable to reproduce the problem using the TurboVNC server. On Tue, Oct 13, 2015 at 3:05 PM, DRC <[email protected]> wrote:
> 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
