Description of problem: This problem shows up when using convert from imagemagick in Redhat 5.3 and 5.4. Trying to convert some pdf files to jpg crashes with the errors below--including key ones from ghostscript. We tried updating imagmagick to a newer version on one box with no luck. We tried a Fedora 11 system because ghostscript is at the current release 8.64 in Fedora and the files convert with no problems. Why is ghostscript in RH 5.4 so old? 8.15.2 was released in 2004. What sense does this make? I see a ton of bugs against it when searching your bugzilla instance which have resulted in patching it like crazy. Given that Fedora seems to have newer versions doesn't it make sense to pull a newer version? Version-Release number of selected component (if applicable): Ghostscript in RH 5.x => 8.15.2 How reproducible: This only happens on some of the pdf files we have. It may be specific to one program that the creative department is using on a Mac to create the pdf. Someone else may not be able to reproduce it without a file from us. Steps to Reproduce: The convert command we are using is $ /usr/bin/convert -colorspace rgb test.pdf test.jpg Actual results: Running /usr/bin/convert -colorspace rgb test.pdf test.jpg ERROR: /rangecheck in --.discardtransparencygroup-- Operand stack: --dict:13/13(L)-- 1 --dict:11/17(L)-- Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1 3 %oparray_pop 1 3 %oparray_pop 1 3 %oparray_pop --nostringval-- --nostringval-- 2 1 1 --nostringval-- %for_pos_int_continue --nostringval-- --nostringval-- --nostringval-- --nostringval-- 1 %stopped_push --nostringval-- --nostringval-- --nostringval-- 1 %stopped_push --nostringval-- --nostringval-- --nostringval-- %array_continue --nostringval-- false 1 %stopped_push --nostringval-- %loop_continue --nostringval-- 17372 --nostringval-- 3 12 %oparray_pop --nostringval-- false 1 %stopped_push 3 12 %oparray_pop --nostringval-- --nostringval-- Dictionary stack: --dict:1127/1686(ro)(G)-- --dict:0/20(G)-- --dict:107/200(L)-- --dict:107/200(L)-- --dict:104/127(ro)(G)-- --dict:241/347(ro)(G)-- --dict:20/24(L)-- --dict:4/6(L)-- --dict:21/32(L)-- --dict:1/1(ro)(G)-- --dict:7/8(L)-- --dict:1/1(ro)(G)-- --dict:2/5(L)-- --dict:1/1(ro)(G)-- --dict:9/13(L)-- Current allocation mode is local Last OS error: 2 ESP Ghostscript 815.02: Unrecoverable error, exit code 1 convert: Postscript delegate failed `test.pdf'. convert: missing an image filename `test.jpg'. Expected results: Expect it to work without errors like newer ghostscript does. Additional info: Fedora 11 and Ubuntu 9.04 have ghostscript 8.64 which works great. I can upload a 22M test file if the system will take one that big. This is not a problem with newer versions of ghostscript so the fact that someone else may not be able to reproduce easily does not negate the fact that this is a real problem for us. We have a php web site which needs to convert uploaded pdfs and cannot because of the old buggy ghostscript. That said, I don't care if ghostscript gets updated or you backport every bugfix from the newer version to the 8.15 version as long as we dont run into these issues.
I couldn't upload the file. It is too big. I put it here but it may not stay if we redo this site in the next year as planned. http://www.kahalacorp.com/jt/ghostscriptCrasher.pdf
This looks like ghostscript bug #689805, still unresolved: http://bugs.ghostscript.com/show_bug.cgi?id=689805 It boils down to the amount of memory required to render the PDF when transparency is involved. How much memory does this installation have, and how much do the Fedora 11 and Ubuntu 9.04 installations have? We generally don't provide new versions of packages during an existing Red Hat Enterprise Linux release except in specific circumstances where backporting a required fix or feature is not feasible. This helps us keep Red Hat Enterprise Linux predictable and consumable, limiting the number of surprises. Backporting ghostscript-8.70 to Red Hat Enterprise Linux would certainly introduce new and unexpected bugs.
The Production server running RH 5.4 has 4G of RAM. The Ubuntu system has 2G. The Fedora system has 384M. I can keep digging if we need to see how much RAM is being allocated to apache and other related processes. I get the reason for be careful about backports but gs 8.15 came out in 2004. RH 6 better have a more recent version. ;)
There were CUPS compatibility issues in ghostscript after 8.15, which is why we are shipping the ESP GS version based on the 8.15 upstream release.
I am attaching a very simple file which fails the conversion.
Created attachment 363997 [details] pdf that fails conversion
Can we expect this bug to be fixed in the near future and rolled out to RH 5.4? or should we pursue workarounds?
Given the lack of progress on this bug (or at least lack of updates here) we have setup a separate box for the problematic site NOT running on Redhat.
Apologies for the lack of updates. When I try that file here I get a different traceback (/BXlevel undefined), which suggests the upstream bug may be 688787 instead -- and *that* one is fixed upstream. Will try that fix locally and see if it works.
Should the status on this be marked upstream? I noticed some ghostcript updates so I tried again. commands fail with: /usr/bin/convert -verbose -colorspace rgb a.pdf a.jpg **** Warning: An error occurred while reading an XREF table. **** The file has been damaged. This may have been caused **** by a problem while converting or transfering the file. **** Ghostscript will attempt to recover the data. [ghostscript library] -q -dBATCH -dSAFER -dMaxBitmap=500000000 -dNOPAUSE -dAlignToPixels=0 -dEPSCrop "-sDEVICE=pnmraw" -dTextAlphaBits=4 -dGraphicsAlphaBits=4 "-g1161x1782" "-r72x72" "-sOutputFile=/tmp/magick-XXJ7bjf6" "-f/tmp/magick-XXbTXrau" "-f/tmp/magick-XXFlTH5R"ERROR: /undefined in /BXlevel Operand stack: 11 0 1 --dict:6/6(ro)(G)-- obj Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1 3 %oparray_pop 1 3 %oparray_pop 1 3 %oparray_pop --nostringval-- --nostringval-- --nostringval-- --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push --nostringval-- %loop_continue --nostringval-- Dictionary stack: --dict:1127/1686(ro)(G)-- --dict:0/20(G)-- --dict:107/200(L)-- --dict:107/200(L)-- --dict:104/127(ro)(G)-- --dict:241/347(ro)(G)-- --dict:18/24(L)-- Current allocation mode is local ESP Ghostscript 815.02: Unrecoverable error, exit code 1 Start of Image Define Huffman Table 0x00 0 1 5 1 1 1 1 1 1 0 0 0 0 0 0 0 Define Huffman Table 0x01 0 3 1 1 1 1 1 1 1 1 1 0 0 0 0 0 Define Huffman Table 0x10 0 2 1 3 3 2 4 3 5 5 4 4 0 0 1 125 Define Huffman Table 0x11 0 2 1 2 4 4 3 4 7 5 4 4 0 1 2 119 End Of Image convert: Postscript delegate failed `a.pdf'. convert: missing an image filename `a.jpg'.
Since I made comment #2 there has been extensive regression testing and fixing performed on ghostscript-8.70 for Red Hat Enterprise Linux 5. Converting this file using the new package works here. Watch for a future update...
*** This bug has been marked as a duplicate of bug 545821 ***