kevinj@boulder.Colorado.EDU (Kevin M. Jackson) (08/16/89)
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 -------------------------------dpm@cs.cmu.edu (David Maynard) (08/16/89)
> 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. Well, just as another (successful) data point, I recently used gcc 1.35 to compile: X11R3 + fixes 1-10 + Purdue 2.0 + Purdue 2.1 on a Sun-2 (yes, a Sun-2) under SunOS 3.5 I used "-traditional -O -finline-functions -fstrength-reduce -DPURDUE" as my compile flags. There was one file in server/cfb which tickled the signal 11 bug in gcc so I manually compiled it without the optimizations. I also recompiled dbm.c and malloc.c with gcc so I didn't need the pcc-struct-return option. The compile took 12 hours, but seemed to yield a working server. I had to use /bin/cc on the libraries and some clients. I haven't tested it thoroughly, but haven't had any server problems so far (using unix:0, localhost:0, or hostname:0). Perhaps the SunOS 3.5 vs 4.0.X difference is significant here. I would tend to suspect a gcc 1.35 problem since the Purdue speedups would seem fairly benign. (The Sun-2 server doesn't use the bitfield optimizations in the Purdue speedups so that could be relevant, although I doubt it.) -David Maynard --- David P. Maynard (dpm@cs.cmu.edu), Dept. of Electrical and Computer Engineering Carnegie Mellon University, Pittsburgh, PA 15213 ---
tadguy@cs.odu.edu (Tad Guy) (08/17/89)
I had the savme problem with my Xsun server when compiled with gcc-1.35 for sun3 under SunOS 4.0.3 (yum yum). The problem went away when I stopped trying to -finline-functions. Try not using that option... To the person who had a file in cfb trash gcc with a signal 11, try installing Spaf's color hacks -- with them installed I could compile *everything* with gcc-1.35. So far no problems... ...tad