Bug 692816

Summary:	Issue when using pipe as output
Product:	GhostPCL	Reporter:	Marcos H. Woehrmann <marcos.woehrmann>
Component:	PCL interpreter	Assignee:	Marcos H. Woehrmann <marcos.woehrmann>
Status:	RESOLVED FIXED
Severity:	normal
Priority:	P4
Version:	master
Hardware:	PC
OS:	Linux
Customer:		Word Size:	---

Description Marcos H. Woehrmann 2012-01-26 05:53:00 UTC

There are occasional indeterminisms when using a pipe as an OutputFile in GhostPCL.  Specifically, the following commands sometimes produce the "wrong" result:

./pcl6 -sOutputFile='| cat >./pipe.pbm' -sDEVICE=pbmraw -r75 -dNOPAUSE -dBATCH ./fts.0120

md5sum pipe.pbm


I've only observed the problem while a regression test is running, it appears related to either a heavy cpu load and/or a large number of disk i/o transactions.  The frequency at which it occurs varies with the computer, on my i7 and on Henry's macpro the problem occurs infrequently, 1 or 2 times out of 500.  On peeves it occurs more frequently, 1 time out 20.

Note the similar set of commands:

./pcl6 -sOutputFile=./file.pbm -sDEVICE=pbmraw  -r75 -dNOPAUSE -dBATCH ./fts.0120

md5sum file.pbm

never fail, so it appears to be an issue with piped output.  I've also not been able to make Ghostscript fail in this way.

I've created directories on macpro and peeves (~marcos/pipe) that contain shell scripts (pipe.sh and file.sh) that run the above commands 500 times and log the md5sums, just remember to run clusterpush and wait until the tests are started before running the tests.

Comment 1 Marcos H. Woehrmann 2012-01-26 14:52:12 UTC

Further testing shows that directing OutputFile to stdout via '-' does not result in indeterminisms:

./pcl6 -sOutputFile=- -sDEVICE=pbmraw -r75 -dNOPAUSE -dBATCH ./fts.0120 | cat >./stdout.pbm

md5sum stdout.pbm

Comment 2 Henry Stiles 2012-03-20 23:04:48 UTC

If you still see it Marcos, assign it back, thanks.

commit dcf401ee8172aaff5363b2fc86e166f73225e429
Author: Henry Stiles <henry.stiles@artifex.com>
Date:   Tue Mar 20 16:56:36 2012 -0600

   Close the device before exiting PCL, XPS and friends.

   The languages deallocated the memory associated with a device but
   never did the associated gs_closedevice().  This might have some
   effect on 692816 where indeterminate output was observed on stdout.
   Without the close device call the "OutputFile" was never actually
   closed (fclose), and so there might have been a missing flush.  All of
   that is speculation, I wasn't able to reproduce the indeterminism -
   but we want the closedevice anyway so here it is.

diff --git a/pl/plmain.c b/pl/plmain.c
index 60c66ea..333dbce 100644
--- a/pl/plmain.c
+++ b/pl/plmain.c
@@ -621,10 +621,10 @@ pl_main_universe_dnit(
          return -1;
      }

-    /* dealloc device if sel'd */
+    /* close and dealloc the device if selected. */
    if (universe->curr_device) {
+        gs_closedevice(universe->curr_device);
        gs_unregister_root(universe->curr_device->memory, &device_root, "pl_main_universe_select");
-        /* ps allocator retain's the device, pl_alloc doesn't */
        gx_device_retain(universe->curr_device, false);
        universe->curr_device = NULL;
    }


Summary of changes:
 pl/plmain.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

Comment 3 Marcos H. Woehrmann 2012-03-22 18:24:39 UTC

I can confirm the problem is fixed.  Many thanks for finding this.  It simplifies regression testing.