clyde@ut-emx.UUCP (Head UNIX Hacquer) (07/20/88)
The X11R2 xterm fails when told to use any display other than 'unix:0.0'. This is on a SUN 3/[56]0, running SunOS 4.0. Witness the below debugging session... spica> dbx xterm ... (dbx) catch 1 (dbx) run -display spica:0.0 Running: xterm -display spica:0.0 stopped in main at line 244 in file "main.c" 244 int fd1 = -1; (dbx) c signal HUP (hangup) in close at 0x33ace close+8: rts (dbx) where close(0x52ad0) at 0x33ace yp_unbind(0x529f0) at 0x34063 yp_get_default_domain(0x529f0, 0xeffe980) at 0x34219 _yp_dobind(0x529f0, 0xeffe980) at 0x33eb5 yp_match(0x529f0, 0x4b887, 0xeffe9b4, 0x4, 0xeffe9cc, 0xeffe9c8) at 0x3574f getpwent(0x3ed, 0x51ea4) at 0x2fd59 getpwent(0xeffeb10, 0xeffef14, 0x3ed) at 0x2f973 getpwuid(0x3ed) at 0x2f36d spawn(), line 1046 in "main.c" main(argc = 0, argv = 0xefffc0c, 0xefffc18), line 549 in "main.c" (dbx) quit ... I have tried building xterm with and without optimization, the X libraries with and without optimization, dynamic and static linking, and I get the same error. Anyone have any ideas? I think that the Sun YP code is busted! -- Shouter-To-Dead-Parrots @ Univ. of Texas Computation Center; Austin, Texas clyde@emx.utexas.edu; ...!ut-sally!ut-emx!clyde "That would be the easy way, but it wouldn't be The Cowboy Way." -Riders in the Sky
pinkas@happy.intel.com (Israel Pinkas ~) (07/20/88)
In article <4328@ut-emx.UUCP> clyde@ut-emx.UUCP (Head UNIX Hacquer) writes: > The X11R2 xterm fails when told to use any display other than 'unix:0.0'. > This is on a SUN 3/[56]0, running SunOS 4.0. Witness the below debugging > session... [dbx session deleted] > I have tried building xterm with and without optimization, the X libraries > with and without optimization, dynamic and static linking, and I get the > same error. > Anyone have any ideas? I think that the Sun YP code is busted! I have the same problem on a Sun386i with X10.4 (SunOS 4.0). I can get xterm to use any display name if I have a local entry in the passwd file. But if it relies on YP for getpwent(), only unix:0 works. I have reported it as a bug to Sun. Has anybody seen this on anything except SunOS? If so, what was your fix? And was YP involved? -Israel -- -------------------------------------- Disclaimer: The above are my personal opinions, and in no way represent the opinions of Intel Corporation. In no way should the above be taken to be a statement of Intel. UUCP: {amdcad,decwrl,hplabs,oliveb,pur-ee,qantel}!intelca!mipos3!cadev4!pinkas ARPA: pinkas%cadev4.intel.com@relay.cs.net CSNET: pinkas%cadev4.intel.com
bst@alice.UUCP (07/22/88)
Since I'm sure a lot of people are going to be hitting this problem as they move to SUN OS4.0, here is copy of a bug report I sent to xbugs a few weeks back. This fix I've given here is not the most elegant possible, but it works. VERSION: X11 release 2 CLIENT MACHINE: Sun 3/110 CLIENT OPERATING SYSTEM: SunOS 4.0 SYNOPSIS: xterm does not work under SUN OS 4.0 on a yellow pages client. DESCRIPTION: xterm dies with a HANGUP message when run under OS4.0. The problem only occurs when running on a YP client. The new OS now keeps a file descriptor open that is a socket connected to the yp server. This reduces the overhead in making YP calls. Xterm, however, assumes that it knowns about all open file descriptors and manually dups the pseudo-tty fds into file descriptors 4 and 5. Since 4 ends up being the YP socket, this hopelessly confuses the YP routines. FIX: Diffs for xterm/main.c 920,921c919,920 < if (screen->respond < 3) { < int newrespond = dupHigh (screen->respond); --- > if (screen->respond != Xsocket + 1) { > dup2 (screen->respond, Xsocket + 1); 923c922 < screen->respond = newrespond; --- > screen->respond = Xsocket + 1; 932,933c931,932 < if (tty < 3) { < int newtty = dupHigh (tty); --- > if (tty != Xsocket + 2) { > dup2 (tty, Xsocket + 2); 935c934 < tty = newtty; --- > tty = Xsocket + 2; 1476,1494d1474 < } < < int dupHigh(oldfd) < { < int desc[3],i,j; < /* Find an fd > 2 */ < for (i=0;i<3;i++) { < desc[i] = dup(oldfd); < if (desc[i] > 2) < break; < } < if (i==3) { < fprintf(stderr,"dupHigh failed\n"); < exit(1); < } < /* Close unneeded ones */ < for (j=0;j<i;j++) < close(desc[j]); < return desc[i];
pinkas@happy.intel.com (Israel Pinkas ~) (08/01/88)
bst@alice.uucp (at AT&T Bell Labs, Murray Hill) posted a set of diffs for xterm that allowed it to run under SunOS 4.0. Unfortunately, he posted a diff file that was reversed. Fortunately, I used patch, which caught this. Enclosed is a context diff. This was done after installing bst's patches on my X10.4 sources. bst had originally posted the diffs for X11.2, but they installed in my source offset by ~200 lines without a problem. To desribe the problem, I run X10.4 on a Sun386i running YP. When I don't have a local passwd entry (as we like to do), I would get an error message from xterm right after clicking with the left button during the create window. xterm would bomb out. The error message was: xterm: Error 31, errno 5: We discovered that this only happend when DISPLAY was set to something other than unix:0. According to bst's post (dated 7/21), the error was due to the YP file descriptor being open. Anyway, it works for me in X10.4. It should work with X11.2, but I have no way of testing it. I also can't test whether this will break xterm on anything else. -Israel Pinkas ---------------------------------------------------------------------- *** main.c.orig Fri Jun 10 14:55:54 1988 --- main.c Mon Aug 1 17:20:54 1988 *************** *** 1143,1152 **** get_pty (&screen->respond, &tty); ! if (screen->respond != Xsocket + 1) { ! dup2 (screen->respond, Xsocket + 1); close (screen->respond); ! screen->respond = Xsocket + 1; } /* change ownership of tty to real group and user id */ --- 1143,1152 ---- get_pty (&screen->respond, &tty); ! if (screen->respond < 3) { ! int newrespond = dupHigh (screen->respond); close (screen->respond); ! screen->respond = newrespond; } /* change ownership of tty to real group and user id */ *************** *** 1155,1164 **** /* change protection of tty */ chmod (ttydev, 0622); ! if (tty != Xsocket + 2) { ! dup2 (tty, Xsocket + 2); close (tty); ! tty = Xsocket + 2; } /* set the new terminal's state to be the old one's --- 1155,1164 ---- /* change protection of tty */ chmod (ttydev, 0622); ! if (tty < 3) { ! int newtty = dupHigh (tty); close (tty); ! tty = newtty; } /* set the new terminal's state to be the old one's *************** *** 1531,1533 **** --- 1531,1553 ---- return(ret); } #endif opcode + + + int dupHigh(oldfd) + { + int desc[3],i,j; + /* Find an fd > 2 */ + for (i=0;i<3;i++) { + desc[i] = dup(oldfd); + if (desc[i] > 2) + break; + } + if (i==3) { + fprintf(stderr,"dupHigh failed\n"); + exit(1); + } + /* Close unneeded ones */ + for (j=0;j<i;j++) + close(desc[j]); + return desc[i]; + } -- -------------------------------------- Disclaimer: The above are my personal opinions, and in no way represent the opinions of Intel Corporation. In no way should the above be taken to be a statement of Intel. UUCP: {amdcad,decwrl,hplabs,oliveb,pur-ee,qantel}!intelca!mipos3!cadev4!pinkas ARPA: pinkas%cadev4.intel.com@relay.cs.net CSNET: pinkas%cadev4.intel.com