Bug 689793

Summary:	gs8.62 exits too soon when reading from gv
Product:	Ghostscript	Reporter:	William Bader <williambader>
Component:	Regression	Assignee:	Ray Johnston <ray.johnston>
Status:	RESOLVED WONTFIX
Severity:	normal	CC:	christinedelight.top85
Priority:	P4
Version:	8.62
Hardware:	PC
OS:	Linux
Customer:		Word Size:	---
Attachments:	gv-gs-bug.ps gsgv.gif gs8.62-dsc.pat gv-3.5.8.pat gv.ini gslog.tar.bz2

Description William Bader 2008-04-14 20:28:22 UTC

When gs runs under gv and empties the pipe, the new stream code in gs behaves
like it hit an eof when it needs to wait for more data.  gs8.53 and gs8.33 work
fine, but gs8.57 through gs8.62 get errors.  If you reopen the file in gv, gs
gets errors in a different place each time.  Older versions of gs are fine, so
this is a regression and not a problem with gv.  You can also confirm that gv is
working by creating a script called gs that captures a copy of the stream before
passing it to ghostscript.  Also, the errors are more likely in situations where
gv does more work and gs does less work, for example, with gv "respect document
structure" enabled, "antialias" disabled, and a "0.1" scale factor.  It is also
more likely on multi-core platforms.
It does not happen with some other viewers like ggv because they have
permanently disabled "respect document structure".

Comment 1 William Bader 2008-04-14 20:30:09 UTC

Created attachment 3936 [details]
gv-gs-bug.ps

This is a big file that shows the problem on my system.

Comment 2 William Bader 2008-04-14 20:31:15 UTC

Created attachment 3937 [details]
gsgv.gif

Screen capture showing an include page and a gs error.

Comment 3 William Bader 2008-04-14 20:32:43 UTC

Created attachment 3938 [details]
gs8.62-dsc.pat

Patches in my version of gs8.62.  The problem happens with a vanilla gs8.62
also.

Comment 4 William Bader 2008-04-14 20:33:56 UTC

Created attachment 3939 [details]
gv-3.5.8.pat

Patches to my version of gv-3.5.8.

Comment 5 William Bader 2008-04-14 20:37:17 UTC

Created attachment 3940 [details]
gv.ini

My $HOME/.gv file which contains the options I am using.  "respectdsc" is the
most important.

Comment 6 William Bader 2008-04-15 21:30:21 UTC

Created attachment 3942 [details]
gslog.tar.bz2

bzip2 tar archive of a successful run and some gs failures with gs -dDEBUG -E
-Zs

Comment 7 William Bader 2008-04-15 21:35:22 UTC

This might be another instance of 689752.

Comment 8 William Bader 2008-04-26 13:21:23 UTC

Running under valgrind and with streams debug enabled produces the section
below.  The bug.ps file displayed correctly without getting errors.  I suspect
that these are "normal" issues with X, but they might be related to the problem
and it is chance whether the uninitialized values cause damage.

resmp ResourceFileName end
resmp ResourceStatus end
cidcm GetCIDSystemInfo end
rewriting TempMapsNotDef
...FINISHED...
*** code space ranges ***
0
        [(\000\000) (\377\377)]
*** defined charmap ***
0
        [() (\002\001\000\002) (\000\000\377\377) (\000\000) 0]
*** undefined charmap ***
*** Content of .CodeMapData ***
0
        [[] [(\000\000) (\377\377)]]
1
        [[] [() (\00==32109== Syscall param writev(vector[...]) points to
uninitialised byte(s)
==32109==    at 0x7D2078: writev (writev.c:46)
==32109==    by 0x9CC312: _xcb_conn_wait (xcb_conn.c:167)
==32109==    by 0x9CC85A: _xcb_out_send (xcb_out.c:279)
==32109==    by 0x9CC98C: _xcb_out_flush_to (xcb_out.c:297)
==32109==    by 0x9CCADE: xcb_flush (xcb_out.c:244)
==32109==    by 0x903E66: _XSend (xcb_io.c:235)
==32109==    by 0x903F17: _XReadEvents (xcb_io.c:208)
==32109==    by 0x8EB48A: XNextEvent (NextEvent.c:50)
==32109==    by 0x8118DFC: x_output_page (gdevx.c:336)
==32109==    by 0x8196548: gs_output_page (gsdevice.c:134)
==32109==    by 0x807CC96: zoutputpage (zdevice.c:349)
==32109==    by 0x8055FC8: interp (interp.c:1534)
==32109==  Address 0x40C53E4 is 4,372 bytes inside a block of size 8,552 alloc'd
==32109==    at 0x4004864: calloc (vg_replace_malloc.c:279)
==32109==    by 0x9CC500: xcb_connect_to_fd (xcb_conn.c:221)
==32109==    by 0x9CEB98: xcb_connect (xcb_util.c:252)
==32109==    by 0x90337F: _XConnectXCB (xcb_disp.c:78)
==32109==    by 0x8EBD68: XOpenDisplay (OpenDis.c:168)
==32109==    by 0x811E47B: gdev_x_open (gdevxini.c:108)
==32109==    by 0x8118C0A: x_open (gdevx.c:255)
==32109==    by 0x8196BDC: gs_opendevice (gsdevice.c:357)
==32109==    by 0x8196D52: gs_setdevice_no_erase (gsdevice.c:419)
==32109==    by 0x807D10D: zsetdevice (zdevice.c:459)
==32109==    by 0x8055FC8: interp (interp.c:1534)
==32109==    by 0x8053633: gs_call_interp (interp.c:496)
==32109==
==32109== Syscall param writev(vector[...]) points to uninitialised byte(s)
==32109==    at 0x7D2078: writev (writev.c:46)
==32109==    by 0x9CC312: _xcb_conn_wait (xcb_conn.c:167)
==32109==    by 0x9CC85A: _xcb_out_send (xcb_out.c:279)
==32109==    by 0x9CD06F: xcb_send_request (xcb_out.c:55)
==32109==    by 0x902D0E: _XPutXCBBuffer (xcb_lock.c:148)
==32109==    by 0x90307A: _XCBUnlockDisplay (xcb_lock.c:31)
==32109==    by 0x8F0C81: XPutImage (PutImage.c:1033)
==32109==    by 0x81194C3: x_copy_mono (gdevx.c:458)
==32109==    by 0x82C5D19: gx_image_cached_char (gxccache.c:409)
==32109==    by 0x81BA1AB: show_proceed (gxchar.c:1144)
==32109==    by 0x81B947D: continue_show (gxchar.c:783)
==32109==    by 0x81B9419: gx_show_text_process (gxchar.c:760)
==32109==  Address 0x40C576A is 5,274 bytes inside a block of size 8,552 alloc'd
==32109==    at 0x4004864: calloc (vg_replace_malloc.c:279)
==32109==    by 0x9CC500: xcb_connect_to_fd (xcb_conn.c:221)
==32109==    by 0x9CEB98: xcb_connect (xcb_util.c:252)
==32109==    by 0x90337F: _XConnectXCB (xcb_disp.c:78)
==32109==    by 0x8EBD68: XOpenDisplay (OpenDis.c:168)
==32109==    by 0x811E47B: gdev_x_open (gdevxini.c:108)
==32109==    by 0x8118C0A: x_open (gdevx.c:255)
==32109==    by 0x8196BDC: gs_opendevice (gsdevice.c:357)
==32109==    by 0x8196D52: gs_setdevice_no_erase (gsdevice.c:419)
==32109==    by 0x807D10D: zsetdevice (zdevice.c:459)
==32109==    by 0x8055FC8: interp (interp.c:1534)
==32109==    by 0x8053633: gs_call_interp (interp.c:496)
2\001\000\002) (\000\000\377\377) (\000\000) 0]]
2
        [[]]
.ProcessICCcomment found %%BeginICCProfilecidcm GetCIDSystemInfo beg
resmp ResourceStatus beg /HeiseiMin-W3-83pv-RKSJ
resmp ResourceFileName beg HeiseiMin-W3-83pv-RKSJ

Comment 9 Ray Johnston 2012-08-10 08:04:43 UTC

Since 8.62 is so old, and so many things have changed, closing this.

If this still happens with 9.06 or later, please reopen with a new
description (reference 9.06) and describe the conditions needed to
reproduce.

Hard to tell how to categorize this -- INVALID or WONTFIX, so I chose
WONTFIX since we aren't going back to do anything to 8.62