clyde@ut-ngp.UUCP (03/26/87)
*** Yet another in a series of X boo-boos (collect them all)! ***
Uwm and derivitatives (such as menuwm) will fail on SUNs if DISPLAY
is NOT set to "unix:0". This is because on the SUN, gethostbyname()
causes RPC and YP calls. Deep (and I mean DEEP) in the YP code, there
is use of the system call call 'bind()'. Now, in 'gram.y' there is
a routine named, you guessed it, 'bind()'.
FLAME ON !!
DAMMIT, DON'T USE THE NAMES OF ANYTHING IN SECTIONS 2 OR 3 OF THE
UNIX PROGRAMMERS' MANUAL AS YOUR OWN ROUTINE NAMES!!!
This is pure unalloyed stupidity! It causes the most insidious
kind of errors which are a real pain to track done even with source,
and totally screws users who don't have source!
FLAME OFF ..
Now, this fix and another fix for a null-dereferncing error found in
menuwm. [ HEY GUYS, the whole damn world doesn't use a VAX! ]
--------------- CUT HERE ------------------------
*** gram.y.r1.1 Wed Mar 25 17:19:59 1987
--- gram.y Wed Mar 25 17:19:01 1987
***************
*** 137,143
case IsNowFunction:
case IsFunction:
if ($3 == C_MAP) {
! bind($1, bkmask, cmask, NULL);
} else yyerror("illegal construct");
break;
case IsDownFunction:
--- 138,144 -----
case IsNowFunction:
case IsFunction:
if ($3 == C_MAP) {
! Bind($1, bkmask, cmask, NULL);
} else yyerror("illegal construct");
break;
case IsDownFunction:
***************
*** 148,154
yyerror(msg);
}
if ($3 == C_MAP) {
! bind($1, bkmask, cmask, NULL);
} else yyerror("illegal construct");
break;
case IsMenuMap:
--- 149,155 -----
yyerror(msg);
}
if ($3 == C_MAP) {
! Bind($1, bkmask, cmask, NULL);
} else yyerror("illegal construct");
break;
case IsMenuMap:
***************
*** 159,165
yyerror(msg);
}
if ($3 == C_MENUMAP) {
! bind($1, bkmask, cmask, menu_name);
} else yyerror("illegal construct");
break;
case IsMenu:
--- 160,166 -----
yyerror(msg);
}
if ($3 == C_MENUMAP) {
! Bind($1, bkmask, cmask, menu_name);
} else yyerror("illegal construct");
break;
case IsMenu:
***************
*** 525,531
/*
* Bind button/key/context to a function.
*/
! bind(index, mask, context, name)
int index; /* Index into keyword table. */
short mask; /* Button/key/modifier mask. */
int context; /* ROOT, WINDOW, or ICON. */
--- 526,532 -----
/*
* Bind button/key/context to a function.
*/
! Bind(index, mask, context, name)
int index; /* Index into keyword table. */
short mask; /* Button/key/modifier mask. */
int context; /* ROOT, WINDOW, or ICON. */
***************
*** 643,653
{
MenuLine *ptr;
! if(!list) list = line;
! for(ptr = list; ptr->line; ptr = ptr->line) /* NULL */;
! ptr->line = line;
! ptr = ptr->line;
! ptr->line = NULL;
return(list);
}
--- 644,659 -----
{
MenuLine *ptr;
! if (line == NULL)
! return(NULL);
! if (list == NULL)
! list = line;
! else {
! for(ptr = list; ptr->line; ptr = ptr->line) /* NULL */;
! ptr->line = line;
! ptr = ptr->line;
! ptr->line = NULL;
! }
return(list);
}
--
Shouter-To-Dead-Parrots @ Univ. of Texas Computation Center; Austin, Texas
clyde@ngp.cc.utexas.edu; ...!ut-sally!ut-ngp!clyde
"It's a sort of a threat, you see. I've never been very good at them
myself, but I've told they can be very effective."jg@jumbo.UUCP (03/26/87)
In article <4892@ut-ngp.UUCP> clyde@ut-ngp.UUCP (Head UNIX Hacquer) writes: > > [ HEY GUYS, the whole damn world doesn't use a VAX! ] > The null dereferencing problem flames should be directed both at Berkeley and Ma Bell rather than us, both had the opportunity, but never bothered to make page 0 inaccessable because of the work involved. I heartily agree the current situation is a crock, and would be first in line to propose a new a.out type on the Vax with page 0 mapped out, but the fact has been that both at MIT and inside DEC Suns are uncommon and were hard for us to get access to. (At Athena, VAXstations and RT/PC's are all of the machines there are....). We have spent weeks of our time trying to make X as portable as possible (I spent 3 days of the last week linting the V11 Xlib), and on the whole I think history has shown succeeded, but that is the difference between a $100 source tape with no guarantees and supported vendor code. As a DEC employee working on Athena, it was my responsibility to make the device independent code work on the VAX and the RT, but not Sun, Apollo, IS, etc.... So please don't begrudge the vendors some money for the supported versions; you do (often) get what you pay for. Many people have made major contributions from all directions; that X runs (or occasionally limps) on the rediculously huge number of machines/displays it does astounds me. So please direct flames in the appropriate directions, and keep posting the fixes (without flames....). And PLEASE make SURE you include the MIT release number and rcsid version of the file from which you made your diffs! - Jim
bzs@bu-cs.UUCP (03/28/87)
>The null dereferencing problem flames should be directed both at Berkeley >and Ma Bell rather than us, both had the opportunity, but never bothered >to make page 0 inaccessable because of the work involved. I heartily >agree the current situation is a crock, and would be first in line to >propose a new a.out type on the Vax with page 0 mapped out, but the fact >has been that both at MIT and inside DEC Suns are uncommon and were hard >for us to get access to. I dunno Jim, maybe we're picking nits here cuz the bugs'll get fixed anyhow but I think if DEC wants their window system pushed as a standard maybe they should buy a SUN or two to test it on. I notice that SUN has a Vax or two (and tested NFS on it.) You could fall into worse traps than null pointers w/o test hardware (and what about that public SUN on the 5th floor of 545, they're around.) Anyhow, I think as usual e-mail communications are misinterpreted. What sounds like a raving flame was probably intended as a constructive suggestion. Code that de-refs null pointers probably has other bugs also, it's just a very noticeable, very fundamental bug. I don't think the issue was only portability to other vendor's hardware, most of us scream these things at ourselves even more loudly. -Barry Shein, Boston University
jg@jumbo.UUCP (03/28/87)
The fact is that software is best tested on the machines on which one works day by day. And the situation is that those machines allow that class of bug to go undetected. At Project Athena, we were restricted to IBM and DEC hardware, and to get any access to a Sun I had to go to a different group and beg machine access. (Athena is NOT in Tech Square). Worrying about how well things ran on a Sun is almost completely irrelevant to the aims of that project; Athena has its hands full just getting things to work well on DEC and IBM hardware. Bob Scheifler's group at the time in Tech Square is also Vax based; the few Suns there were in machine rooms and typically nearly unused, not being the personal platform of any of the people. X has now outgrown its origins, and some re-examination of how things should be handled is now in order. In a commercial company, the competitor's hardware is very hard to come by, since it costs real money rather than the internal transfer cost. Such machines in any company tend to be orphans, not properly set up or maintained, and not used on a day to day basis for real work. Most often, they are used intermittantly to get an idea what the competition is up to. The net result is that things do not get the workout they deserve. One of the problems we are now facing is how to do a better job on V11 than could be done given the situation at MIT during V10 development; I believe it would be a good idea for the companies involved to be able to set up machines in one place on one network for testing. The logistical questions of how and where to set such a situation up are challenging, and it would be valuable for this to be discussed in this news group, or alternatively, in the private alpha-tester's mailing list. Jim Gettys
JMEADS@ADA20.ISI.EDU.UUCP (03/29/87)
Jim,
For a few years now, I've been a believer that a good windows system is one that
will work in a heterogeneous environment where a user's workstation can be in
communication with several remote and independent hosts simultaneously and
capable of providing a window for every job the user has currently executing on
any host.
My understanding is that neither X nor any other window system is currently
capable of operating in such an environment. (Maybe some future version!!) But
if it were, then testing would be a "simple" matter of running an appropriate
test routine on the machines to be tested from a single workstation.
I realize that the logistics of arranging such testing may be as challenging as
developing a system that can operate under such a system. But I can dream.
Jon Meads
Portland, Oregon
{jmeads@ADA20.ISI.EDU}
-------treese@ATHENA.MIT.EDU.UUCP (03/29/87)
> For a few years now, I've been a believer that a good windows system is one > that will work in a heterogeneous environment where a user's workstation can > be in communication with several remote and independent hosts simultaneously > and capable of providing a window for every job the user has currently > executing on any host. > > My understanding is that neither X nor any other window system is currently > capable of operating in such an environment. (Maybe some future version!!) > But if it were, then testing would be a "simple" matter of running an > appropriate test routine on the machines to be tested from a single > worksation. If I understand your "wish" correctly, then X can in fact handle this. X supports windows that communicate through network connections; the machines do not have to be the same. Currently, on my VAXstation II, I have windows from a couple of RTPC workstations. I could just as easily create one from a Sun that had X. > I realize that the logistics of arranging such testing may be as challenging > as developing a system that can operate under such a system. But I can > dream. The problem that Jim faces in testing X is that one must verify that X clients from a variety of workstations are able, in fact, to interact properly with X display servers running on those different machines. It is also desirable for X applications to compile and run properly without change on different workstations -- that is the problem that shows up with dereferencing NULL pointers on Suns that didn't appear on VAXen. Performing such testing thoroughly means having easy access to well-maintained systems from many vendors. That's the tricky part. > Jon Meads > Portland, Oregon > {jmeads@ADA20.ISI.EDU} Win Treese MIT Project Athena treese@athena.MIT.EDU
yba@bacchus.UUCP (03/29/87)
In article <5794@bu-cs.BU.EDU> bzs@bu-cs.BU.EDU (Barry Shein) writes: > >I dunno Jim, maybe we're picking nits here cuz the bugs'll get fixed >anyhow but I think if DEC wants their window system pushed as a >standard maybe they should buy a SUN or two to test it on. (I thought this was still MIT's window system.) Seems reasonable most vendors will support their own testing, and SUN certainly seems to be doing so, judging by their comments. The part I find amusing is that empty references are being considered a "portability problem" rather than an error in the first place? In any case, having DEC buy a SUN would lead to asking them to buy one of each of 90 or so other machines -- donations to MIT would be great if only we could support all that hardware....
bzs@bu-cs.UUCP (03/29/87)
Correction to my note: ...but I think if DEC wants their window system pushed as a standard... Should probably have read ...but I think if DEC and IBM wants MIT's X accepted as an industry-wide, multi-vendor window standard... Apologies for bruised whatevers... -Barry Shein, Boston University
guy@gorodish.UUCP (03/30/87)
Another alternative to buying Suns for testing (yeah, I know, I should be getting people to buy *lots* of Suns, but, well...) - grab John Bruner's changes to 4BSD to support "no-page-zero" executables, and build all programs as "no-page-zero" executables. (I wish Berkeley would grab those changes and make "no-page-zero" images the *default*; if you have old stupid code, you can ask the linker to make it a "zero-at-location-zero" image. For that matter, I wish AT&T would make "no-page-zero" images the default on *their* machines, etc., etc..)
jdb@mordor.UUCP (03/31/87)
It has been some time since I've worked on it, but back in 4.2BSD I made some (relatively minor) changes to the kernel and a few utility program to implement a page-0-invalid executable format. The file format is identical to 0413 (ZMAGIC, -z) except for two things: (1) the magic number is 0420, (2) the first page of the text segment is filled with zeros and the entry point is 1024, not 0. The kernel doesn't map page 0, so a reference to NULL causes a bus error. The loader recognizes the new flag "-Z" and zero fills the first page. There is a change to "nlist.h"; most programs which look at object files in the standard ways need no (or minor) changes. Back in the late summer of 1985 I reimplemented these changes in beta 4.3BSD. A summary of the changes to beta 4.3 is available for anonymous FTP on MORDOR.S1.GOV as the file "z0magic". Since I made these changes I've done a lot of other things to our VAX kernel (e.g. installing NFS), so I can't provide a diff against a standard 4.3 kernel without some more work. If there is sufficient interest I'll try to put together a version based upon vanilla 4.3. However, my time for UNIX is pretty limited right now, so I can't promise speedy action. -- John Bruner (S-1 Project, Lawrence Livermore National Laboratory) MILNET: jdb@mordor.s1.gov (415) 422-0758 UUCP: ...!ucbvax!decwrl!mordor!jdb ...!seismo!mordor!jdb
geoff@eagle_snax.UUCP (03/31/87)
In article <8703290507.AA00924@CIROCCO.MIT.EDU>, treese@ATHENA.MIT.EDU (Win Treese) writes: > The problem that Jim faces in testing X is that one must verify that X clients > from a variety of workstations are able, in fact, to interact properly with > X display servers running on those different machines. It is also desirable > for X applications to compile and run properly without change on different > workstations -- that is the problem that shows up with dereferencing NULL > pointers on Suns that didn't appear on VAXen. > > Performing such testing thoroughly means having easy access to well-maintained > systems from many vendors. That's the tricky part. > We ran into the same problem at Sun: how to verify that all of the NFS ports were interoperable. What we've done (twice now) is to hold a "Connectathon" multivendor testing session a few weeks before the winter Uniforum show, and get everybody's machine in a single room, running NxN compatibility tests. Each lasts a week, and they've been the most gruelling and exhilarating engineering experiences I've ever had. All it took was $$$ from Sun to rent the space and multi-person-weeks of energy from the NFS Consulting Group to get the test suites ready. Plus, of course, the commitment of one or more systems plus engineering talent from the vendors. Now, who's volunteering to do this for X? Should be a lot of fun..... -- [content-free messages need no disclaimer. is this content-free? who knows] Geoff Arnold, Sun Microsystems East Coast Division (home of PC-NFS) UUCP: {ihnp4,decwrl,...}!sun!garnold <OR> decvax!eagle_snax!geoff