Created attachment 20354 [details] the test pdf file that causes Ghostscript to hang The following command to extract images form the test file (in attachment): gs9.53.3\bin\gswin64c.exe -dSAFER -dBATCH -dNOPAUSE -dNOPROMPT -dMaxBitmap=500000000 -dUseCropBox -dAlignToPixels=0 -dGridFitTT=2 -sDEVICE=png16m -dTextAlphaBits=4 -dGraphicsAlphaBits=4 -dPDFFitPage -dFirstPage=1 -dLastPage=3 -dDEVICEWIDTH=860 -dDEVICEHEIGHT=1113 -sOutputFile=c:\Temp\test\test-%d.png c:\Temp\test\test.pdf hangs forever (tried to wait more than 12 hours) : GPL Ghostscript 9.53.3 (2020-10-01) Copyright (C) 2020 Artifex Software, Inc. All rights reserved. This software is supplied under the GNU AGPLv3 and comes with NO WARRANTY: see the file COPYING for details. Processing pages 1 through 3. Page 1 Page 2 the test file is a part of big file that also could not be processed by Ghostscript
Created attachment 20355 [details] Simplified sample file This is a regression; v.9.50 works fine, v.9.51 and higher fail. The simplest command line is: gs FOO.pdf The bug is related on overprint, tiled patterns, and smooth shading used together.
Based on Peter's evaluation, assigning to Michael -- He's been VERY active in this area in the not too distance past. Changing to UNCONFIRMED until Michael can validate the issue.
Created attachment 20356 [details] Experimental patch Bisection shows that this bug was introduced by the commit 55a7a41998f35ae23aedf2fdb83698dde1453d58 . Effectively undoing it restores normal operation of the current development version.
Passing to Robin based upon the bisect results
This patch breaks page 14 of tests_private/xl/pcl6cet3.0/C305.bin.pbmraw.600.1..pcl And page 17 of tests_private/xl/pcl6cet3.0/C421.bin.pbmraw.600.1..pcl And page 10 of tests_private/xl/pcl6cet3.0/C422.bin.pbmraw.600.1..pcl And pages 7 and 9 of tests_private/xl/pcl6cet3.0/C603.bin.pbmraw.600.1..pcl And page 24 of tests_private/xl/pcl6cet/c329.bin.pbmraw.600.1..pcl And page 1 of tests_private/xps/xpsfts-a4/fts_33xx.xps.bitrgbtags.300.1..xps tests_private/xps/xpsfts-a4/fts_33xx.xps.pbmraw.72.0..xps And page 2 of tests_private/xps/xpsfts-a4/fts_34xx.xps.bitrgbtags.300.1..xps tests_private/xps/xpsfts-a4/fts_34xx.xps.ppmraw.72.0..xps The rest of the diffs look good though.
Going back to first principles here, and reproducing the initial problem in a debug build (actually a memento build), with 9.53.3 I see we get an infinite number(*) of "No encode_color proc defined for device." errors. (*May not actually be infinite). This doesn't happen with the latest code, so it looks like it has been fixed since. We do get a SEGV with the latest version to do with gdev_prn_close attempting to access through a NULL ppdev->bg_print, but with the trivial fix for that it's fine. I will investigate some more.
This occurs because of the pattern-clist playback. A simple Windows command line is: -dFirstPage=1 -dLastPage=1 j6.pdf The end of pattern-clist playback is what closes the flp device.
Back to Robin who is re-working the compositor interface. I had determined it was due to the pattern_clist playback being confused into switching devices because of an overprint compositor action (when there was a 'clipper' forwarding device installed). This needed some analysis, and a change to the return information from the create_compositor device proc.
Fixed with: commit a754bd375a625368567947b1e1b77ce3e5c06a3f Author: Robin Watts <Robin.Watts@artifex.com> Date: Mon Feb 22 19:57:35 2021 +0000 Bug 703265: Tweak create_compositor device method. Update create_compositor device method, so that it always returns the compositor device (or the leaf device if there is no specific compositor device). The device now returns 1 if we created a compositor device to wrap the given device. This should enable us to identify exactly the cases where forwarding devices need to update which device they forward to. In particular, this allows us to remove the horribly fragile code in apply_create_compositor in gxclrast.c, and to ensure that we correctly identify the 'new compositor' case. This avoids us sending stuff to the wrong device, and having to cope with a slew of warnings.
Created attachment 20666 [details] 703265.patch This is the real patch. The one from Peter simply masks the problem because it alters the clip path.