Created attachment 10494 [details] snip of CUPS log + pdf2ps tool 'test case' Hi, I while attempting to print a pdf with CUPS on a HP LaserJet Pro 400 MFP M525dn I experienced a 'filter failure'. I was able to trace this down to a segmentation fault in the gs binary. It was found that the shell script pdf2ps uses the ps2write device and thus nothing to do with CUPS. See the relevant <snip> from the CUPS log and the pdf2ps tool retriggering the problem in the attached 'testcase.txt' file. Attached in the following are the IRC log chatting about the issue for background if needed and the pdf. Note the pdf is copyrighted and so should probably be removed from public downloading after this is fixed? Cheers, Edward.
Created attachment 10495 [details] IRC chat log.
Created attachment 10496 [details] pdf that is the issue. Disclaimer: copyrighted pdf (not by me) and so should be removed or whatever after issue has been identified.
Oh and I forgot to add, if useful: $ gs --version 9.10 $ uname -ms Linux x86_64 Let me know if there is anything else.
Created attachment 10497 [details] A copy of /usr/bin/pdf2ps
This is a 535 page PDF file, could you not at least state which page causes the problem ? It doesn't look likely that the JPXDecoder is at fault, since it cleanly exits with an error. Where did you get Ghostscript ? Did you build it yourself from source, or pick up a Linux distribution (if so, which one) ? What options (if any) were supplied to the pdf2ps script ?
(In reply to comment #5) > This is a 535 page PDF file, could you not at least state which page causes > the problem ? It doesn't look likely that the JPXDecoder is at fault, since > it cleanly exits with an error. Yes sorry, I miss categoried it as "PS Writer" slipped my eye. I saw JPXDecoder and so picked that as the closes approx. Sorry about the pdf size, I don't know which page is at fault, simply feeding it into pdf2ps quickly makes the ps2writer (backend?) device seg fault. If I knew a simpler test case I could of narrowed it down more or even sent in a patch myself so would be happy to hear how that is done.. > > Where did you get Ghostscript ? Did you build it yourself from source, or > pick up a Linux distribution (if so, which one) ? Distro, in particular this package: https://www.archlinux.org/packages/extra/x86_64/ghostscript/ As far as I can see, its compiled in a pretty stock standard way with no distro so called patching which tends to break things. https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/ghostscript > > What options (if any) were supplied to the pdf2ps script ? No options, just feed the pdf in as can be seen in attachment 10494 [details]. Thanks for looking into this, Edward.
(In reply to comment #6) > Distro, in particular this package: > https://www.archlinux.org/packages/extra/x86_64/ghostscript/ > > As far as I can see, its compiled in a pretty stock standard way with no > distro so called patching which tends to break things. I am not a Linux build expert (ours is on vacation) but that linked page contains this line: # force it to use system-libs rm -rf jpeg libpng zlib jasper expat tiff lcms lcms2 freetype openjpeg cups/libs # jbig2dec is in community Using shared system libraries is one of our gripes with distributions. We test Ghostscript quite extensively, but always using specific versions of the 3rd party libraries we require. Distributions are zealous about using system shared libraries and that can lead to problems. When I test your file here, using the versions of the libraries we ship, I don't get a JPX error, and I happen to know that *our* version of the OpenJPEG libraries incorporates patches (which have been supplied upstream). So I would suggest that you either get our binary: http://www.ghostscript.com/download/gsdnld.html Or build from source and *don't* use system shared libraries. I strongly suspect either will work.
(In reply to comment #7) > (In reply to comment #6) > > > > Distro, in particular this package: > > https://www.archlinux.org/packages/extra/x86_64/ghostscript/ > > > > As far as I can see, its compiled in a pretty stock standard way with no > > distro so called patching which tends to break things. > > I am not a Linux build expert (ours is on vacation) but that linked page > contains this line: > > # force it to use system-libs > rm -rf jpeg libpng zlib jasper expat tiff lcms lcms2 freetype openjpeg > cups/libs # jbig2dec is in community > > > Using shared system libraries is one of our gripes with distributions. We > test Ghostscript quite extensively, but always using specific versions of > the 3rd party libraries we require. Distributions are zealous about using > system shared libraries and that can lead to problems. > > When I test your file here, using the versions of the libraries we ship, I > don't get a JPX error, and I happen to know that *our* version of the > OpenJPEG libraries incorporates patches (which have been supplied upstream). > > So I would suggest that you either get our binary: > > http://www.ghostscript.com/download/gsdnld.html > > Or build from source and *don't* use system shared libraries. I strongly > suspect either will work. I just attempting to do a make debug build from source of that package in the hopes of obtaining a backtrace of some kind. Which library in particular is connected to this issue that you 'suspect'..? It seems weird since Arch is very current being a rolling release and all.. I havn't tried it on one of my FreeBSD machines yet.. Could you please provide your OS and library versions? Many Thanks, Edward.
(In reply to comment #8) > I just attempting to do a make debug build from source of that package in > the hopes of obtaining a backtrace of some kind. Which library in particular > is connected to this issue that you 'suspect'..? OpenJPEG, because you see a JPX error which I don't. > It seems weird since Arch > is very current being a rolling release and all.. I havn't tried it on one > of my FreeBSD machines yet.. Could you please provide your OS and library > versions? I'm using Fedora 14, 64-bit, not using any system libraries except obviously gcc, I'd have to reboot the system to give you the version though.
(In reply to comment #9) > (In reply to comment #8) > > > I just attempting to do a make debug build from source of that package in > > the hopes of obtaining a backtrace of some kind. Which library in particular > > is connected to this issue that you 'suspect'..? > > OpenJPEG, because you see a JPX error which I don't. > > > It seems weird since Arch > > is very current being a rolling release and all.. I havn't tried it on one > > of my FreeBSD machines yet.. Could you please provide your OS and library > > versions? > > I'm using Fedora 14, 64-bit, not using any system libraries except obviously > gcc, I'd have to reboot the system to give you the version though. You are correct, thank you ! OpenJPEG is very out of date and it looks to be a bug in the Haar filter that was later solved. I report this back to the distro package maintainer. Can this around for a background on the issue? Thanks again for narrowing this down, Edward.
Hello Edward, you reported the ppmraw device ran to completion without crashing which would imply the jpeg2000 decoder was not responsible for the crash since the exact same decoding process would happen as occurred in the original problem, we would predict a crash with the ppmraw device. Maybe you didn't run it to completion?
I'll re-open this for the moment because I actually don't understand the issue since I can't seem to obtain a backtrace at the moment nor do I understand how all these libraries fit together. I also have the run around: https://bugs.archlinux.org/task/38226#comment117555 Cheers, Edward.
(In reply to comment #11) > Hello Edward, you reported the ppmraw device ran to completion without > crashing which would imply the jpeg2000 decoder was not responsible for the > crash since the exact same decoding process would happen as occurred in the > original problem, we would predict a crash with the ppmraw device. Maybe > you didn't run it to completion? I ran: `gs -sDEVICE=ppmraw -o foo.ppm FILENAME.pdf` and it completes just fine.. If I compile openjpeg 2.0.0 from source and over write the libraries installed on the system the issues goes away. Once I revert the changes the issue ofcourse returns. So for now, from the outside it does 'look like' the issue stems from openjpeg. Please see the distro comments. Many Thanks,
I'd much prefer to leave this issue *closed* unless there is new evidence to open it again. Otherwise it keeps popping up on my list. From my POV the issue is resolved as the current code works. I don't know what you want me to make of the distros comments.
(In reply to comment #15) > I'd much prefer to leave this issue *closed* unless there is new evidence to > open it again. Otherwise it keeps popping up on my list. From my POV the > issue is resolved as the current code works. > > I don't know what you want me to make of the distros comments. That's fine since I believe this is a distro issue also now, atleast at the moment. The distro does however 'claim' the following: "The code hasn't landed in GS 9.10 but only in git master. We will have to wait for a release including these fixes." Does that mean a `impending release` is coming soon to include these fixes? Sorry to sound 'pushy'.. I sort of have to break my package manager to make my printer work :p Any way, will stop spamming here I guess since I sort of feel like the message boy that's about to get shot.. Kind Regards, Edward.
(In reply to comment #16) > "The code hasn't landed in GS 9.10 but only in git master. We will have to > wait for a release including these fixes." That is not exactly true. 9.10 works just fine, because it uses our modified version of the OpenJPEG library. If you build from source and don't insist on shared system libraries, then Ghostscript 9.10 does not suffer the problem. *These* fixes are in released code. The change to use OpenJPEG 2.0 is not in released code, but that's not the same thing at all. We run into this problem from time to time because the distributions will insist on using shared system libraries. > Does that mean a `impending release` is coming soon to include these fixes? Ghostscript is released at approximately 6 monthly intervals, the next release will be in the New Year, probably around March time. > Any way, will stop spamming here I guess since I sort of feel like the > message boy that's about to get shot.. Only if you keep putting the bug back to 'unconfirmed'.....
Sorry to jump in here, but it's probably worth pointing out that if the problem lies with the distros use of a system OpenJPEG library, then the new release of Ghostscript will possibly NOT solve the problem. Yes, we move to OpenJPEG v2, but it's quite possible that the same fixes will be required in that. We've done various fixes in OpenJPEG (both v1 and v2) and either have or are in the process of pushing them back upstream, but when a release of OpenJPEG with these fixes in will be forthcoming is not clear. The only safe route is to build with our bundled (patched) versions.