See attached gsc -dBATCH -dNOPAUSE -dUseCropBox -sDEVICE=tiffsep -sOutputFile=./test -r300 -f /storage/archive/20889PGW355.pdf gsc -dBATCH -dNOPAUSE -dUseCropBox -sDEVICE=tiffsep -sOutputFile=./test -r300 -f 20889PGW355.pdf GPL Ghostscript GIT PRERELEASE 9.08 (2013-01-29) Copyright (C) 2012 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. Processing pages 1 through 1. Page 1 %%SeparationName: S05373 %%SeparationName: S01854 %%SeparationName: S03782 %%SeparationName: S09174 %%SeparationName: S04395 %%SeparationName: Varnish %%SeparationName: Die %%SeparationName: S05375 Error: /rangecheck in --showpage-- Operand stack: 1 true Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1900 1 3 %oparray_pop 1899 1 3 %oparray_pop 1883 1 3 %oparray_pop --nostringval-- --nostringval-- 2 1 1 --nostringval-- %for_pos_int_continue --nostringval-- --nostringval-- 1777 0 9 %oparray_pop --nostringval-- --nostringval-- Dictionary stack: --dict:1165/1684(ro)(G)-- --dict:1/20(G)-- --dict:82/200(L)-- --dict:82/200(L)-- --dict:109/127(ro)(G)-- --dict:292/300(ro)(G)-- --dict:27/32(L)-- --dict:6/8(L)-- --dict:21/40(L)-- Current allocation mode is local GPL Ghostscript GIT PRERELEASE 9.08: Unrecoverable error, exit code 1 Segmentation fault
Created attachment 10016 [details] file that demonstrates bug
For me this fails in clist_get_bits_rect_mt() which I believe makes it a clist problem, so I'm assigning it to Ray. The error starts from tiffsep_print_page(), line 2095: for (y = 0; y < height; ++y) { code = gx_downscaler_get_bits_rectangle(&ds, ¶ms, y); When y is 410. Running at a lower resolution (and therefore not involving the clist) works correctly. Its not obvious to me why we get a Seg fault afterwards, but it looks like memory is corrupted when we try to do a vmreclaim at the end of the job. Possibly whatever is causing the get_bits problem is also corrupting the memory pool, fixing one might well fix both. This fails for me on Windows on a debug build, and using the debugger (yay!)
making this a P2 since it is a segfault
This is now behaving for me on windows in both debug and memento builds. I will try to reproduce it tomorrow on linux, and maybe bisect to find a fix point.
I can reproduce this on commit 200dc186 (25/6/2013, the day Kens commented). Fixed in: commit 47294ff5b168d25bfc7db64f51572d64b8ebde91 Author: Michael Vrhel <michael.vrhel@artifex.com> Date: Thu Oct 20 13:53:06 2016 -0700 Bug 697345 Blend Color Space Support for Separation devices This is a rather large commit that brings support for transparency blend color spaces to the separation devices. Previously the transparency compositor always used CMYK for the blend color space if the output device was a separation device. With this commit: If the blend space is RGB or Gray based, then we now ensure that the alternate tint transform is not used when we encounter a separation or DeviceN color space. (assuming we have not run out of spot color space at the target device). Note that if the any of the spot colors in a DeviceN color space are CMYK process colorants and the blend space is Gray or RGB, the alternate tint transform IS used. 2) The pdf14 compositor now handles a mixture of additive and subtractive components. I.e. RGB + spots or Gray + spots. 3) If the blend mode is non white preserving or not separable, then the spot colors use the normal blend mode while the process colorants use the specified blend mode. 4) In the process there was a bit of code clean up. But much remains to be cleaned.