The customer reports that Ghostscript generates a "Error: /stackoverflow in --run--" when reading the file 27742.pdf. I've duplicated this issue with gs8.54, gs8.64, and head (r9505). The command line I'm using for testing: bin/gs -sDEVICE=ppmraw -o test.ppm ./27742.pdf Because of the files large size it can be found in casper:/home/support/690307
The sample file defines a dictionary with about 40000 elements. Ghostscript uses operators -<<-- and -->>-- to construct the dictionary and overflows the operand stack.
So, why not just bump up our MaxOpStack parameter when parsing PDF's ?
Created attachment 4833 [details] patch Following Adobe implementation, copy only a few top elements of the stack to the corresponding element of the $error dictionary when the stack overflows. Adobe copies up to 500 top elements, we copy up to 65535. This feature enables Ghostscript to have maximum stack sizes larger than 65535. The maximum operand stack size is set to 100000 to match Adobe interpreters. The large stack size is needed for some PDF files that construct large dictionaries using << ... >> operators.
The patch is committed as a rev. 9536. CET 27-05.ps prints the maximum stack sizes, the operand stack size is now equal to Adobe's.