See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612010. Please reviiew security implication if any Copied verbatim here: There's a problem with how gs handles procedure definitions. This works fine: (echo "1 dict dup /MaxOpStack 100000 put setuserparams {"; \ yes 1 | head -60000 ; echo "} quit") | gs -q -dNODISPLAY - However, this causes a very obscure rangecheck error: (echo "1 dict dup /MaxOpStack 100000 put setuserparams {"; \ yes 1 | head -70000 ; echo "} quit") | gs -q -dNODISPLAY - And in fact any procedure definition of similar size will fail in the same way. I delved into the problem, and it seems that it's a simple overflow problem: in iscan.c:658 gs tries to build a large array of size > 65536, but, as seen in iref.h:370, object sizes are stored in a 16 bit integer. The allocation succeeds, but its size is wrong. Hence, trouble.
Large stacks don't mean that arrays can be large too. The size of the array is currently limited by the short field in the ref structure, which stores object length. We want to increase maximum object sizes but this change is not planned for the upcoming release. This patch just checks the array size and throws /limitcheck error if the array length exceeds 65535 elements. http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=61fd8053c2c0b653df3d461b791ca3f61767c4f5