Created attachment 8000 [details] the PDF that results in failure Here are the steps I'm taking: [bhapca@portal test]$ gs --version 9.04 [bhapca@portal test]$ gs -dBATCH -dNOPAUSE -dSAFER -sDEVICE=pdfwrite -sOutputFile=tt.pdf March_Digital_App.pdf GPL Ghostscript 9.04 (2011-08-05) Copyright (C) 2011 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. Processing pages 1 through 84. Page 1 Page 2 Page 3 <snip> Page 84 [bhapca@portal test]$ gs -dSAFER -dBATCH -dNOPAUSE -sDEVICE=png16m -dTextAlphaBits=4 -dGraphicsAlphaBits=4 -dUseCropBox -sOutputFile=pngs/image-%d.png -r100 tt.pdf GPL Ghostscript 9.04 (2011-08-05) Copyright (C) 2011 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. Processing pages 1 through 84. Page 1 Page 2 Page 3 Page 4 Page 5 Page 6 Page 7 Page 8 Page 9 Page 10 Page 11 Error: /unregistered in --run-- Operand stack: --dict:9/18(L)-- 1 11 3 ( **** Error reading a content stream. The page may be incomplete.\n) Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1894 1 3 %oparray_pop 1893 1 3 %oparray_pop 1877 1 3 %oparray_pop --nostringval-- --nostringval-- 12 1 84 --nostringval-- %for_pos_int_continue --nostringval-- --nostringval-- --nostringval-- Dictionary stack: --dict:1158/1684(ro)(G)-- --dict:1/20(G)-- --dict:83/200(L)-- Current allocation mode is local Last OS error: 2 GPL Ghostscript 9.04: Unrecoverable error, exit code 1 [bhapca@portal test]$
GS 9.04 runs this file to completion for me. Are you using the archive we distribute with our default build? Or are you using a distribution package, or a modified build in some way (using different third party libs to the ones we supply, for example)?
Thanks for looking into this so quickly ! I'm using GS built from sources, with files time-stampped Aug 5. It's a straight build, on CentOS, with no changes or 3rd party libs. (In reply to comment #1) > GS 9.04 runs this file to completion for me. > > Are you using the archive we distribute with our default build? Or are you > using a distribution package, or a modified build in some way (using different > third party libs to the ones we supply, for example)?
(In reply to comment #2) > Thanks for looking into this so quickly ! > > I'm using GS built from sources, with files time-stampped Aug 5. It's a > straight build, on CentOS, with no changes or 3rd party libs. That's the same sources I'm testing with, on Ubuntu 10.10, so that makes life a little difficult because obviously we need to reproduce the problem before we can attempt to fix it. Is there any other pertinent information you can supply that might help reproduce the problem?
Works for me, tested on AMD64, gcc 4.5.1, gs v.9.04, debug, release x86, gcc 4.3.2, gs 9.04, release
I can appreciate the difficulty of investigating this if it can't be reproduced. For what is worth, I'm attaching the whole console output of performing a fresh install and running the test again. I'm running this on a cloud server from Rackspace, which they claim to be a CentOS 5.4 image, although the login console shows: portal login: CentOS release 5.5 (Final) Kernel 2.6.35.4-rscloud on an x86_64 If it can't be reproduced on your side, hence with slim chances of getting a fix, it looks like I need to apply a workaround. As you can see, I'm using GS in 2 steps, first as a pass-trough filter for the PDF, aimed to remove any JPEG2000 compression, then the resulting PDF I'm trying to break it into PNGs. It's the 2nd step that fails, but interestingly enough if fails only if applied on the result of the pass-through. If I apply the same step on the original PDF it works, so here's the chance for my workaround. (In reply to comment #3) > (In reply to comment #2) > > Thanks for looking into this so quickly ! > > > > I'm using GS built from sources, with files time-stampped Aug 5. It's a > > straight build, on CentOS, with no changes or 3rd party libs. > > That's the same sources I'm testing with, on Ubuntu 10.10, so that makes life a > little difficult because obviously we need to reproduce the problem before we > can attempt to fix it. > > Is there any other pertinent information you can supply that might help > reproduce the problem?
Created attachment 8003 [details] console output showing a fresh install followed by the problem
Sorry, the bug title confused me. It's not that GS can't process the attached PDF, but it can't process the PDF that the pdfwrite device produces from the attached PDF. I was able to reproduce it on both 9.04 and master.
Created attachment 8046 [details] ih2.pdf.bz2 - simplified sample file This file has a few images that have identical data in the image and SMask streams. Our pdfwtite device creates a self-referencing masked image that causes infinite recursion in the PDF interpreter.
Ken, I'm reassigning this bug to you. A patch for PDF interpreter will be committed later today.
A patch to the PDF interpreter has been committed as: http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=6dc04dcacd37256f8d0c61cec49975ba67297873
Ken, please close if Alex's patch is satisfactory.
(In reply to comment #11) > Ken, please close if Alex's patch is satisfactory. Alex's patch (I think) only fixes the problem in the PDF interpreter, it seems to me that we shouldn't be creating such a file in the fist place.
As far as I can see this bug no longer exists. Unfortunately the simplified file is still exceedingly complex, which makes it hard to be sure. The fdile still contains dozens of Smasks. However I am unable to see any self-references in the output, and if I remove Alex's patch to the PDF interpreter, so that the file should fail, then the output PDF file still runs to completion. So I'm closing this as WORKSFORME