Created attachment 6532 [details] Offending PDF file: f10test.pdf I am trying out the current SVN state (rev 11538) of Ghostscript. I have compiled with "make so" on Linux and run Ghostscript directly from the source tree without installing: cat ~/ghostscript/gpl/testfiles/f10test.pdf | LD_PRELOAD=sobin/libgs.so.9.00 GS_LIB=Resource/Init:lib sobin/gsc -dQUIET -dPARANOIDSAFER -dNOPAUSE -dBATCH -sDEVICE=png16m -sstdout=%stderr -sOutputFile=%stdout -r720x720 -dDEVICEWIDTHPOINTS=595 -dDEVICEHEIGHTPOINTS=842 -_ > out.png With the attached input file (f10test.pdf) Ghostscript gets stuck in an infinite loop. I get the same result with reduced resolution ("-r72x72") and also with the "cups" output device. Also this simplified command line makes Ghostscript hanging: LD_PRELOAD=sobin/libgs.so.9.00 GS_LIB=Resource/Init:lib sobin/gsc -sDEVICE=png16m -o out.png ~/ghostscript/gpl/testfiles/f10test.pdf Screen display with X using the command line LD_PRELOAD=sobin/libgs.so.9.00 GS_LIB=Resource/Init:lib sobin/gsc -sDEVICE=x11 ~/ghostscript/gpl/testfiles/f10test.pdf shows an incompletely rendered page in the window and then hangs (screenshot attached). Acrobat Reader displays the file correctly. Also Ghostscript 8.71 has no problems with this file.
Created attachment 6533 [details] Screen shot of the rendering state when Ghostscript hangs
This bug first appears in: r10940 | robin | 2010-03-17 19:57:10 -0500 (Wed, 17 Mar 2010) | 13 lines Merge gs_2_colors branch down to trunk. This adds a new set of color state information to the graphics/imager state, along with a new non-standard postscript operator .swapcolors to toggle between them. The Postscript interpreter is updated to use one set of color information for stroking, and the other for all non-stroking colors. This produces differences in just 2 pdfwrite tests, due to rounding errors due to changes in the way pdf with non-zero rendering modes is emitted now.
Created attachment 6545 [details] the change that causes the loop Reverse-applying this patch to the current version breaks the infinite loop. The patch is not a right way to fix the bug, just a hint where the bug happens.
Created attachment 6546 [details] Simplified sample file
Alex, Thanks for looking into this. Since Robin did this change, I am assigning to him to investigate, and elevating this to 'blocker' until we understand the problem more thoroughly.
Created attachment 6548 [details] h92.pdf - minimal sample file: 844 bytes
This is a problem with the changes I made to the pattern_cache for the gs_2_colors code. What should happen is that the stroke operator will be executed, and notice that a pattern colour is in force, but that it's not cached. It then exits, leaving the stroke operator on the stack, to "prepare" the pattern (i.e. run its paint procedure). When this finishes, the stroke operator is run again, and this time the pattern should be cached. For some reason this isn't working. In looking at this code it has made me reevaluate a decision made while doing the gs_2_colors work, in that I had split the pattern_cache into two. I believed that the pattern_cache contained cached rendered versions of the current colour, but this is not quite true. The pattern_cache is actually a cache of rendered versions, indexed by colour index. This means that multiple different pattern colours can have entries in the cache at once - hence I do not need to have 2 separate pattern caches. This means I can remove the 'alternative' pattern_cache and the code to swap between the two. Local testing shows this solves the infinite loop. A localcluster test looks good too - just confirming with a bmpcmp on the few differences (that I think are indeterminisms).
Robin, I have tried your fix in rev 11548 now and I can confirm that the attached files get correctly rendered now, without infinite loop.