Bug 691493 - Infinite loop when rendering a PDF file
Summary: Infinite loop when rendering a PDF file
Status: RESOLVED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: PDF Interpreter (show other bugs)
Version: master
Hardware: PC Linux
: P4 normal
Assignee: Alex Cherepanov
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-07-23 10:56 UTC by Till Kamppeter
Modified: 2010-07-28 19:21 UTC (History)
0 users

See Also:
Customer:
Word Size: ---


Attachments
Offending PDF file: f10test.pdf (40.17 KB, application/pdf)
2010-07-23 10:56 UTC, Till Kamppeter
Details
Screen shot of the rendering state when Ghostscript hangs (33.00 KB, image/png)
2010-07-23 10:57 UTC, Till Kamppeter
Details
the change that causes the loop (382 bytes, patch)
2010-07-25 03:29 UTC, Alex Cherepanov
Details | Diff
Simplified sample file (30.31 KB, application/octet-stream)
2010-07-25 03:32 UTC, Alex Cherepanov
Details
h92.pdf - minimal sample file: 844 bytes (844 bytes, application/pdf)
2010-07-25 20:23 UTC, Alex Cherepanov
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Till Kamppeter 2010-07-23 10:56:23 UTC
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.
Comment 1 Till Kamppeter 2010-07-23 10:57:39 UTC
Created attachment 6533 [details]
Screen shot of the rendering state when Ghostscript hangs
Comment 2 Alex Cherepanov 2010-07-25 00:41:20 UTC
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.
Comment 3 Alex Cherepanov 2010-07-25 03:29:58 UTC
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.
Comment 4 Alex Cherepanov 2010-07-25 03:32:59 UTC
Created attachment 6546 [details]
Simplified sample file
Comment 5 Ray Johnston 2010-07-25 16:46:07 UTC
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.
Comment 6 Alex Cherepanov 2010-07-25 20:23:46 UTC
Created attachment 6548 [details]
h92.pdf - minimal sample file: 844 bytes
Comment 7 Robin Watts 2010-07-28 18:24:56 UTC
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).
Comment 8 Till Kamppeter 2010-07-28 19:21:04 UTC
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.