Path: utzoo!attcan!uunet!ginosko!rex!ukma!gatech!bloom-beacon!DSYS.NCSL.NIST.GOV!rbj From: rbj@DSYS.NCSL.NIST.GOV (Root Boy Jim) Newsgroups: comp.windows.x Subject: XIO errors again Message-ID: <8907201559.AA15029@dsys.ncsl.nist.gov> Date: 20 Jul 89 15:59:10 GMT Sender: daemon@bloom-beacon.MIT.EDU Organization: National Institute of Standards and Technology formerly National Bureau of Standards Lines: 108 ? From: elan!jlo@AMES.ARC.NASA.GOV (Jeff Lo) ? This subject has appeared before, but I never heard any real definitive ? answers or solutions to the problem. The problem is that sometimes an ? X client seems to fall behind the server, or a very large amount of data ? is being sent between the client and the server, and the server appears ? to send a KillClient, and consequently the client dies. I have heard ? some say that there is a bug in writev and it returns an incorrect ? error code. Others have said that it is caused by buggy unix domain ? sockets (we've gotten the error when client and server were on the same ? machine and when they were not). In any case, it is causing us a lot ? of grief, so I was wondering if anyone has found a fix, a good explanation, ? or even a "Fixed in R4" comment. Thanks! You asked for it. I will repeat my posting. Gurus should save it and repost it whenever this topic reappears. ? From: sumax!amc-gw!brian@beaver.cs.washington.edu (Brian Crowley) ? 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.