Summary: | Error: /stackoverflow in --run-- | ||
---|---|---|---|
Product: | Ghostscript | Reporter: | Marcos H. Woehrmann <marcos.woehrmann> |
Component: | PDF Interpreter | Assignee: | Alex Cherepanov <alex> |
Status: | NOTIFIED FIXED | ||
Severity: | normal | ||
Priority: | P1 | ||
Version: | master | ||
Hardware: | Macintosh | ||
OS: | MacOS X | ||
Customer: | 850 | Word Size: | --- |
Attachments: | patch |
Description
Marcos H. Woehrmann
2009-02-25 14:00:10 UTC
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. |