Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!sri-spam!ames!ucbcad!ucbvax!H.CS.CMU.EDU!Rudy.Nedved
From: Rudy.Nedved@H.CS.CMU.EDU
Newsgroups: mod.computers.laser-printers
Subject: (none)
Message-ID: <1986.11.14.16.5.32.Rudy.Nedved@h.cs.cmu.edu>
Date: Fri, 14-Nov-86 11:20:04 EST
Article-I.D.: h.1986.11.14.16.5.32.Rudy.Nedved
Posted: Fri Nov 14 11:20:04 1986
Date-Received: Wed, 19-Nov-86 22:24:18 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 95
Approved: laser-lovers@washington.arpa

I sent the following message to info-postscript and have
not seen it. Maybe I duplicated it, maybe I sent it to
the wrong address. Sigh.

Anyhow it turns out that the bug fix mention below does not
work and that the working bug fix is to simply depend on
waiting for data to come down the pipe....disable the signal
in psrv and comment out the longjmp/setjmp for waitonreverse.

- - - - Begin forwarded message - - - -
Date: Monday, 10 November 1986 15:51:32 EST
From: Rudy.Nedved@h.cs.cmu.edu
To: info-postscript@sushi.stanford.edu
Subject: Transcript v2.0 bug
Message-ID: <1986.11.10.20.31.11.Rudy.Nedved@h.cs.cmu.edu>

The last few months or so I have been working on stablizing and improving the
roboustness of our printing system after introducing a few CMU features to the
4.3BSD lpd system. As of today, I found a bug I have been trying on and off to
track down for a month. The bug was occasional and would effectively wedged
the queue.

I started working on the theory that the listener process in the Transcript
code was some how confusing the sender when it did a signal over the weekend.
Today, I stepped back from looking at the low level code (fdopen and dup2()
subroutines) and looked at the bigger picture....voila!  A race conditon is the
code design.

Here is the deal, in pscomm.bsd (v2.1 85/11/24) the code for handling
formatting and reversing basically has the potentially for getting seriously
confused. The reverse code which is called frequently at CMU has the following
general design:

	setjmp(waitonreverse);
	if (!revdone) {
	    pipe(fdpipe);
	    if (fork() == 0) {
		/* child code which does signals */
	    }
	    /* parent code */
	    close(0);
	    dup(fdpipe[0]);
	    close(fdpipe[0]);
	    close(fdpipe[1]);
	    streamin = fdopen(0,"r");
	    while (!revdone)
		pause();
	}
	/* send the postscript file */

Well, if the child finishes quickly enough it will generate a signal on the
parent. The parent will set the revdone flag and do a longjmp. The effect is
the close(), dup() and fdopen() sequence is interrupted. If it is fast enough
it will close standard input (fd is 0) and cause a future dup to duplicate
standard output to standard input (since it is the lowest available
descriptor). The end behaviour is the sender wedges waiting for data from the
laserwriter...if any data comes then it sends it back to the
laserwriter...figthing with the listener process for the data from the
laserwriter. The fix is to move the parent code out of the test loop except
for the pause() loop.

Of course, I can believe that v3 of transcript is out and I don't know about
it.

-Rudy
Facilities Staff
Computer Science Department/Robotics Insititute
CMU
- - - - End forwarded message - - - -

I have also found two more failure modes. One bug is in the listener for the
first listen. It has a test like
    while (TRUE) {
	r = getc(psin);
	if (r == EOF) {
		fprintf(stderr, EOFerr, prog, "startup");
		fflush(stderr);
		sleep(20); /* printer may be coming up */
	}
    }
This test will never clear since once the stdio library's EOF bit
is set...the _filbuf() routine will never try to do input again.
It needs a clearerr() call to clear the EOF bit to make _filbuf()
try reading again.

The other bug I am still looking for. It happens when the listener
seems to go away with the parent trying to get the status of the
print....it happens most of the time when someone is spooling from
a 4.2bsd Unix system and the printer is connected to AppleTalk and then
switched over to the serial line. 

In general the transcript code is prone to race conditions between the
various processes involved. 

-Rudy