Path: utzoo!utgpu!watmath!iuvax!rutgers!sunybcs!boulder!kevinj
From: kevinj@boulder.Colorado.EDU (Kevin M. Jackson)
Newsgroups: comp.windows.x
Subject: Xsun server with Purdue dies.
Message-ID: <10774@boulder.Colorado.EDU>
Date: 15 Aug 89 22:39:04 GMT
Reply-To: kevinj@boulder.Colorado.EDU (Kevin M. Jackson)
Organization: University of Colorado, Boulder
Lines: 111


I am having difficulty getting R3 running on a Sun3 with the Purdue speedups.
Below is enclosed a message that was posted here awhile back with a similar
problem.  I, too am using gcc-1.35 and R3 with all patches and Purdue speedups,
and receive the same error, regardless of DISPLAY variable settings.  The
non-purdue version compiled using cc works with no problems, so it must be
a purdue speedup bug or a gcc bug (or an incompatibility between the two).  I
have tried to get the server to run on a sun3/260 and a sun3/110 running
sunOS4.0.3.  

The symptoms of the server problem are identical to those described below:  the
server starts up with stipple pattern and cursor, waits 3-4 seconds, and dies.
No xterm is ever started.  The error message is identical.

If anyone has any other suggestions on how to fix this, let me know.  My
gcc flags are:
             -fcombine-regs -fstrength-reduce -finline-functions 
	     -fpcc-struct-return -DPURDUE -Dinline=INLINE -DNOSTDHDRS

This is the message previously posted to this newgroup:
-------------------------------- cut here -------------------------------------
? I am trying to build and run the R3 distribution on a 3/60CG4 using
? gcc-1.35 and the PURDUE speedups.

? After successfully compiling the World, I try to execute the server
? with the command:

? 	xinit xterm -- -dev /dev/cgfour0

? The grey stipple pattern comes up along with the cursor, then after 3-4
? seconds, I get the error message:

? 	XIO:  fatal IO error 32 (Broken pipe) on X server "unix:0.0"
?               after 38 requests (28 known processed) with 0 events remaining.
?               The connection was probably broken by a server shutdown or
? 	      KillClient.

? and the whole thing dies (laeving the keyboard in a funny state that I can
? only fix with the kbd_mode -a command).

? My questions:

? 	1.  Can anybody tell me what this error message *really* means?

? 	2.  Has anybody else successfully compiled using gcc-1.35?
? 	    Should I be using gcc-1.34?

? 	3.  If I should be using gcc-1.34, anyone tell me where I can
? 	    snarf a copy (UUCP or ftp).

? 	4.  Observations?  Suggestions?

? Of course, thanks in advance.

**** WARNING **** WARNING **** WARNING **** WARNING **** WARNING ****
**** WARNING **** WARNING **** WARNING **** WARNING **** WARNING ****
**** WARNING **** WARNING **** WARNING **** WARNING **** WARNING ****

Do *NOT*, ever, never use `unix:0' as your display. Unless it works.

There are bugs in certains vendors' operating systems regarding them.
Use `localhost:0' or your explicit hostname instead.

I have been thru this before. I am running SunOS 3.5 on a 3/180,
with the 4.0 nameserver kit installed. It redefines netdb.h and
some routines in libc.a, notably gethostbyname.

I see the same behavior with gcc and regular cc.

However, I got a little further than you did.

Symptoms:

I do xinit with no args. An xterm comes up. I can type small amounts
of output with no problems. However, a `cat /etc/termcap' types a few
pages, and then the window dies. I can get about 4K. Sound familiar?
That is the pipe limit. Pipes are unix domain socketpairs. It makes no
difference whether I run uwm or not. I have applied patches 1-9.

I am not sure whether this is your problem, and which vendors and
operating systems versions my notes apply to. Perhaps using the
new networking stuff is a problem, I once had unix:0 working.

The point is that unix domain sockets have always been buggy, and
there is no reason to expect them to work now. Avoid them.

Gurus, please take note. When someone poses you a stumper question
that has this particular XIO error in it, and you have no answer,
please utter this warning with the caveats that it is a last resort,
that it should work, but doesn't always in practice.

In fact, I was led to my conclusions by something RWS said about
the way certain OS's handle writev's in server/4.2bsd/io.c:FlushClient.
He mentioned that EINVAL could be returned under certain circumstances.
Perhaps the specific UNIX error should be reported as well. Perhaps
an attempt should be made to handle EINTR and retry the operation.
I don't see how EINTR could happen, but you never know.

We now return you to your regularly scheduled program.

**** WARNING **** WARNING **** WARNING **** WARNING **** WARNING ****
**** WARNING **** WARNING **** WARNING **** WARNING **** WARNING ****
**** WARNING **** WARNING **** WARNING **** WARNING **** WARNING ****

? Jeff Lo, Elan Computer Group, Inc.
? jlo@elan.com, ..!{ames,uunet}!elan!jlo
? 888 Villa Street, Third Floor, Mountain View, CA 94041, 415-964-2200

	Root Boy Jim
	Have GNU, Will Travel.
------------------------------ end of enclosure -------------------------------