[comp.windows.x] xterm problems with SunOS 4.0

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