The ghostscript parser 8.5[67] fails when parsing immediately evaluated names inside a procedure that spans more than one line, when gs reads the ps code at its stdin. The bug does not happen when Ghostscript reads a file with the same ps code. HOW to reproduce the bug: fireup gs8.57 with no other arguments, then type the following and follow it with a newline (with the intention of typing the closing curly brace on the next line) like so: { //resourceforall Ghostscript will spit out "Error: /syntaxerror in --execute--" and the stack dump and fails to process the PS commands. However if you restart ghostscipt and type "{ //resourceforall }" and then hit return, ghostscript is happy. This bug has appeared between gs8.54 and gs8.56. gnu-ghostscript-8.55 also does not have the bug. please see "script" transcript below for the detailed error message. ----------------------------------------------------------------------- Script started on Fri 27 Jul 2007 03:04:00 PM EDT rep@dinar bin]$ ./gs GPL Ghostscript 8.57 (2007-05-11) Copyright (C) 2007 artofcode LLC, Benicia, CA. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. GS>{ //resourceforall Error: /syntaxerror in --execute-- Operand stack: Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- %loop_continue 1705 2 3 %oparray_pop --nostringval-- --nostringval-- false 1 %stopped_push .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push Dictionary stack: --dict:1081/1123(ro)(G)-- --dict:0/20(G)-- --dict:69/200(L)-- Current allocation mode is local GS>quit [rep@dinar bin]$ [rep@dinar bin]$ [rep@dinar bin]$ [rep@dinar bin]$ ./gs GPL Ghostscript 8.57 (2007-05-11) Copyright (C) 2007 artofcode LLC, Benicia, CA. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. GS>{ //resourceforall } GS<1>quit [rep@dinar bin]$ Script done on Fri 27 Jul 2007 03:04:56 PM EDT
I confirm the problem in the current HEAD on both Linux and Windows platforms. Operators implemented in C are not affected by the bug but everything else is.
This first broke in r6912; I've assigned the bug accordingly.
While low priority, this is Alex's area now and he's made many improvements to address the name binding in our PS code.
Bug still reproducible in Ghostscript 9.03
Ray, please review the logic. We allocate %statementedit in the system memory. When a is read from the command prompt we use gs_scan_token() to determine, whether the line has a complete token. If the line has immediately evaluated names, gs_scan_token() fails. This is interpreted as the end of the input. If the line buffer has a complete token, the buffer is rescanned and everything is fine. Otherwise, scanning a prematurely closed buffer causes an error. All we need to do to fix this is to force local memory allocation instead of inheriting system memory from %statementedit. The scanned token is discarded anyway.
Created attachment 8158 [details] patch
The changes to use system VM were made to cure JOBSERVER issues with some allocations in local _and_ global VM being restored (freed) by a restore to the outermost save level. If, as you say, "The scanned token is discarded anyway.", then this patch should be fine. Testing -dJOBSERVER mode from gswin32c with input from stdin would show up the problems (ref bug 688312 and 201952) as described in commit: commit 3ac6e994cdf2f7065465082f2f90458d61afd92f Author: Ray Johnston <ray.johnston@artifex.com> Date: Fri Jun 30 20:00:21 2006 +0000 Changes to make the JOBSERVER and exitserver operate correctly. This is essential to proper CET and FTS execution. If the command line input still works from stdin, then please commit your patch.
The patch has been committed as: http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=2f12f569672d84a1846905c41701fca52f8dc55e