Bug 690312 - gs stalls, never returns on attached figure
Summary: gs stalls, never returns on attached figure
Status: RESOLVED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: PS Interpreter (show other bugs)
Version: master
Hardware: PC Linux
: P4 normal
Assignee: Ken Sharp
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-03-02 15:06 UTC by keinbiervorvier
Modified: 2009-03-03 08:24 UTC (History)
0 users

See Also:
Customer:
Word Size: ---


Attachments
fig4b.eps (278.85 KB, application/postscript)
2009-03-02 15:08 UTC, keinbiervorvier
Details

Note You need to log in before you can comment on or make changes to this bug.
Description keinbiervorvier 2009-03-02 15:06:59 UTC
Hi,

this applies to current gs HEAD on Fedora F8 and F10 and RHEL 4.

The attached figure stalls gs (X11), gsnd, and ps2pdf. The interpreter appears
to get stuck and never completes/returns. Only part of the figure is displayed. 

Adding a simple noop (2 copy pop pop) to the diamond macro avoids this problem.

> diff -u fig4b.eps fig4b.eps-workaround
--- fig4b.eps   2009-03-02 15:53:24.000000000 -0700
+++ fig4b.eps-workaround        2009-03-02 15:59:34.000000000 -0700
@@ -154,7 +154,7 @@
 /ft4 { t4 f } bind def
 /ot4 { t4 o } bind def
 % Diamond symbol
-/di { moveto dup 0 exch rmoveto
+/di { 2 copy pop pop moveto dup 0 exch rmoveto
       dup neg dup rlineto dup dup neg rlineto
       dup dup rlineto closepath } bind def
 /ddi { di s } bind def

tracing the program execution simply hangs on read

> strace gs fig4b.eps 
....
writev(3,
[{">\2\7\0\3\0@\3\1\0@\3\2\0@\3\211\0/\3\211\0/\3\254\1f\0H\2\26\2"..., 2216},
{"\377\377\377\0\377\377\377\0\377\377\377\0\377\377\377\0\377\377\377\0\377\377\377\0\377\377\377\0\377\377\377\0"...,
55728}], 2) = 57944
read(4, "odi\n13 773 717 odi\n13 775 703 od"..., 4096) = 4096
read(4, "1217 687 odi\n13 1218 684 odi\n13 "..., 4096) = 4096
read(4, "1647 684 odi\n13 1648 689 odi\n13 "..., 4096) = 4096

^C


Cheers
T.
Comment 1 keinbiervorvier 2009-03-02 15:08:31 UTC
Created attachment 4822 [details]
fig4b.eps

gs (X11) does not completely display this figure and does not return
Comment 2 Alex Cherepanov 2009-03-02 18:55:35 UTC
The problem was introduced in rev. 8962.
Comment 3 Ken Sharp 2009-03-03 08:04:50 UTC
Intriguing...

The job provokes a stackoverflow in the setcolor routines. These are handled in
a continuation procedure, but because the overflow is detected after the
continuation procedure is pushed on to the execution stack, GS returns to the
continuation afterwards. This causes the infinite loop, because the stack frame
is no longer valid for a setcolor.

This patch fixes the problem for me, I'm just running a regression test before I
commit it (NB I checked the other continuation routines and found another
potential case):

Index: zcolor.c
===================================================================
--- zcolor.c	(revision 9503)
+++ zcolor.c	(working copy)
@@ -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);
 
Comment 4 Ken Sharp 2009-03-03 08:24:55 UTC
Fixed in revision 9519 with this patch:

http://ghostscript.com/pipermail/gs-cvs/2009-March/009094.html