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".
Created attachment 3936 [details] gv-gs-bug.ps This is a big file that shows the problem on my system.
Created attachment 3937 [details] gsgv.gif Screen capture showing an include page and a gs error.
Created attachment 3938 [details] gs8.62-dsc.pat Patches in my version of gs8.62. The problem happens with a vanilla gs8.62 also.
Created attachment 3939 [details] gv-3.5.8.pat Patches to my version of gv-3.5.8.
Created attachment 3940 [details] gv.ini My $HOME/.gv file which contains the options I am using. "respectdsc" is the most important.
Created attachment 3942 [details] gslog.tar.bz2 bzip2 tar archive of a successful run and some gs failures with gs -dDEBUG -E -Zs
This might be another instance of 689752.
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
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