[gs-cvs] rev 9519 - trunk/gs/psi

[ken at ghostscript.com]

Author: ken
Date: 2009-03-03 08:23:24 -0800 (Tue, 03 Mar 2009)
New Revision: 9519

Modified:
   trunk/gs/psi/zcolor.c
Log:
Fix (colour): Faulty error handling

Details:
bug #690312 "gs stalls, never returns on attached figure"

The job causes the 'base' (Gray, RGB, CMYK) colour code to be executed with a completely
full stack, which causes a stackoverflow because this routine needs to push the colour
space name onto the operand stack.

However, the operand stack wasn't being checked until after the continuation procedure 
had been pushed onto the execution stack, so after the error handling, we returned to
the continuation procedure, but without an appropriate operand stack. This caused a
loop to run without bounds.

Fixed by checking the operand stack beforesetting up the execution stack for the
continuation and aborting if it is full. Desk checking revealed another potential case
of the same problem, fixed in the same patch.

Expected Differences
None


Modified: trunk/gs/psi/zcolor.c
===================================================================
--- trunk/gs/psi/zcolor.c	2009-03-02 19:54:01 UTC (rev 9518)
+++ trunk/gs/psi/zcolor.c	2009-03-03 16:23:24 UTC (rev 9519)
@@ -3725,11 +3725,11 @@
 	     * so that our continuation is ahead of the sub-proc's continuation.
 	     */
 	    check_estack(1);
+	    push(1);
 	    /* The push_op_estack macro increments esp before use, so we don't need to */
 	    push_op_estack(devicencolorants_cont);
 
 	    make_int(pstage, 1);
-	    push(1);
 	    *op = space[1];
 	    code = zsetcolorspace(i_ctx_p);
 	    if (code != 0)
@@ -5606,6 +5606,8 @@
      * so that our continuation is ahead of the sub-proc's continuation.
      */
     check_estack(1);
+    /* May need to push a /Device... name on the stack so make sure we have space */
+    check_ostack(1);
     /* The push_op_estack macro increments esp before use, so we don't need to */
     push_op_estack(setdevicecolor_cont);