Bug 691425 - HEAD: Error: /limitcheck in --run--
Summary: HEAD: Error: /limitcheck in --run--
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
QA Contact: Bug traffic
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-06-25 18:33 UTC by Jason Giglio
Modified: 2010-07-06 23:55 UTC (History)
0 users

See Also:
Customer:
Word Size: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jason Giglio 2010-06-25 18:33:41 UTC
64-bit Linux

gsc -dNOPAUSE -dBATCH -sOutputFile=/dev/shm/test -sDEVICE=tiffsep -r300 -f /storage/archive/01726CLC959.pdf
GPL Ghostscript SVN PRE-RELEASE 8.72 (2010-02-11)
Copyright (C) 2010 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
Error: /limitcheck in --run--
Operand stack:
   --dict:10/19(L)--   0.3   0.3   0.3   0   0   0.3   0.3   0   0   0   0   0   0   --nostringval--
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--   --nostringval--   false   1   %stopped_push   1910   1   3   %oparray_pop   1909   1   3   %oparray_pop   1893   1   3   %oparray_pop   --nostringval--   --nostringval--   2   1   1   --nostringval--   %for_pos_int_continue   --nostringval--   --nostringval--   --nostringval--   --nostringval--   %array_continue   --nostringval--   false   1   %stopped_push   --nostringval--   %loop_continue   --nostringval--   --nostringval--   --nostringval--
Dictionary stack:
   --dict:1157/1684(ro)(G)--   --dict:1/20(G)--   --dict:82/200(L)--   --dict:82/200(L)--   --dict:108/127(ro)(G)--   --dict:292/300(ro)(G)--   --dict:22/25(L)--   --dict:6/8(L)--   --dict:21/40(L)--   --dict:1/1(ro)(G)--   --dict:4/5(L)--
Current allocation mode is local
Last OS error: 2
GPL Ghostscript SVN PRE-RELEASE 8.72: Unrecoverable error, exit code 1
Comment 1 Jason Giglio 2010-06-25 18:34:35 UTC
Created attachment 6405 [details]
01726CLC958.pdf
Comment 2 Jason Giglio 2010-06-25 18:35:17 UTC
Created attachment 6406 [details]
01726CLC959.pdf
Comment 3 Alex Cherepanov 2010-07-06 22:34:12 UTC
Increase the max number of color components to 14 to accommodate
a new record number (13) observed in the wild.

--- gs/base/gsccolor.h  (revision 11491)
+++ gs/base/gsccolor.h  (revision 11492)
@@ -28,11 +28,11 @@
 /*
  * Define the maximum number of components in a client color.
  * This must be at least 4, and should be at least 6 to accommodate
- * hexachrome DeviceN color spaces. We saw 9-component colors in
- * the wild. (bug 691002).
+ * hexachrome DeviceN color spaces. We saw 9-component (bug 691002)
+ * and 13-component (bug 691425) colors in the wild.
  */
 #ifndef GS_CLIENT_COLOR_MAX_COMPONENTS         /* Allow override with XCFLAGS */
-#  define GS_CLIENT_COLOR_MAX_COMPONENTS (12)
+#  define GS_CLIENT_COLOR_MAX_COMPONENTS (14)
 #endif

The patch is committed as a rev. 11492.
Comment 4 Ray Johnston 2010-07-06 22:51:02 UTC
IIRC, we have a file from a user (SmithCo ??) that had 17 components.

Now that the image clues are gone (that caused a severe performance penalty
with larger GS_CLIENT_COLOR_MAX_COMPONENTS values (it used to be 252 to
match Adobe CPSI) why not bump it up to 20 or 32 and give some headroom.

Is there any performance or large memory usage penalty anymore ?
Comment 5 Alex Cherepanov 2010-07-06 23:10:00 UTC
There's no detectable performance difference on all files from comparefiles/ set
between 12 and 14 component settings. I didn't try anything else.

Ray, do you remember which file was particularly slow before?
Comment 6 Ray Johnston 2010-07-06 23:55:55 UTC
Alex, I found an email from you to tech 2008-07-20 that said:

With 256 color components, sizeof(gx_image_enum) == 500K . Such
large objects are allocated in separate chunks. By default, glibc
also allocates them with a separate mmap2() system call. This greatly
reduces performance of the files that have many images, for instance
a sample file from the bug 689722. 

This might be a good one to test with the latest code (without clues)
with a larger number of CLIENT colors vs. 8.71

I guess you could find which of the comparefiles slow down with rev 8863
vs. 8864 (this had image clues and 8863 had 252 components).