vance@mtxinu.UUCP (Vance Vaughan) (11/09/84)
4.2 BUGLIST ABSTRACTS from MT XINU, part 7 of 10: The following is part of the 4.2 buglist abstracts as processed by Mt Xinu. The initial line of each abstract gives the offending program or source file and source directory (separated by --), who submitted the bug, when, and whether or not it contained a proposed fix. Due to license restrictions, no source is included in these abstracts. Important general information and disclaimers about this and other lists is appended at the end of the list... script.c--ucb dlw@ucbopal.CC (David L. Wasley) 22 Nov 83 +FIX Some terminals must be used with parity checking enabled. 'Script' doesn't generate parity so output is garbage. Also, RETURNs aren't stripped from the typescript and foul some other processes. (These come from using the pseudo-tty. They are necessary for the terminal output.) REPEAT BY: Run script on a terminal (eg tvi925) with parity checking enabled. Run 'od' on the typescript file. _______________________________________________________________________________ sed--bin raphael@wisc-crys.arpa (Raphael Finkel) 29 Jun 84 Sed accepts only the pattern forms accepted by ed. Vi has at least one improvement: delimited strings, formed by \< and \>. This feature would enhance sed nicely. FIX: Embed code from ex into sed. _______________________________________________________________________________ see--ucb ogcvax!root@teklabs.UUCP (Bruce Jerrick) 27 Apr 83 +FIX In 4.1c, "/usr/src/ucb/see.sh" (and /usr/ucb/see) needs this added to the top: #! /bin/sh Without it, I get intermittent "see: Command not found." messages. Bruce Jerrick Oregon Graduate Center CSNet: bruce@Oregon-Grad UUCP: ...teklabs!ogcvax!bruce _______________________________________________________________________________ select,getitimer,setitimer--man cbosgd!mark (Mark Horton) 24 Aug 83 +FIX The documentation for select and getitimer should cross reference each other in the SEE ALSO section. There should be a /usr/man/man2/setitimer.2 which is a link to or sources getitimer.2. REPEAT BY: whereis setitimer shows no manual page FIX: As in Description. These two system calls have very similar function - in fact, I was using select to do what setitimer was designed for (a sub-second-resolution sleep). They ought to cross reference each other. I trust you'll also fix the bugs Steve Bellovin pointed out in setitimer. The documentation forgets to mention the first argument; also, setting it to zero to turn it off doesn't work. It's ironic that, even though setitimer was designed to be used as a timer and select wasn't, it's more convenient to use select because you don't have to mess with alarms. Too bad select returns too soon. _______________________________________________________________________________ sendbug--ucb mazama!stew (Stewart Levin) 9 Feb 84 This, though trivial, is too good to pass up. Sendbug itself caused a bug! make clean in /usr/src/ucb died when it entered the subdirectory `sendbug' because the makefile there did not have an entry `clean'. REPEAT BY: cd /usr/src/ucb/sendbug ; make clean FIX: add a clean entry to the makefile _______________________________________________________________________________ sendbug/bugfiler.c--ucb sjk@sri-spam (Scott J. Kramer) 7 Dec 83 When invoked with the -d, -mXXX, *and* maildir options, "bugfiler" returns a usage message and exits. REPEAT BY: bugfiler -d -m644 /usr/bugs/mail => Usage: bugfiler [-d] [-mmsg_mode] [maildir] _______________________________________________________________________________ sendbug/sendbug.sh--ucb hpda!hpdsd!hpdsa!eric 22 Mar 84 +FIX I resent being thrown into vi when reporting a bug. The user's environment should be interrogated for his/her EDITOR or VISUAL variables. REPEAT BY: Type "sendbug". See vi(1) ? FIX: Using your favorite editor, look at /usr/src/ucb/sendbug/sendbug.sh Replace the line... /usr/ucb/vi /tmp/bug$$ with... if ( $VISUAL != "" ) then set editor = $VISUAL else if ( $EDITOR != "" ) then set editor = $EDITOR else set editor = /usr/ucb/vi endif _______________________________________________________________________________ sendmail--lib mcgeer@ucbdali (Rick Mcgeer) 24 Jul 84 sendmail does not accept the following address, which is valid: "gladd tom@lll-mfe.arpa" instead it sends: gladd.tom@lll-mfe.arpa REPEAT BY: send mail to user gladd tom@lll-mfe.arpa, or to the postmaster at that site, "provan don"@lll-mfe.arpa _______________________________________________________________________________ sendmail--usr.lib root@BERKELEY (Fluke ) 5 Dec 83 +FIX If the sendmail alias database is out of date, two concurrent invocations of sendmail could each begin to update it in parallel. The resultant database may be garbaged. REPEAT BY: The following procedure is slightly non-deterministic, but it has been effective for us in provoking the problem 50% of the time: Configure /usr/lib/sendmail.cf for automatic database rebuilding: # rebuild alias database if out-of-date: OD Create /usr/lib/aliases.{dir,pag} % touch /usr/lib/aliases. % mail root </dev/null & % mail root </dev/null & Now the tricky part -- test for bad aliases. A short C program using the dbm(3) routines may be helpful. _______________________________________________________________________________ sendmail--usr.lib mazama!stew (Stewart Levin) 11 Jan 84 After we installed sendmail we were getting messages complaining about unknown system name when mailing letters to each other. We looked around and changed the /usr/include/syslog.h file to reference our own system name rather than "localhost" and reinstalled. Same results. Finally we found that sendmail uses its own private copy of that file and the problem went away after repeating the change in /usr/src/usr.lib/sendmail/include. REPEAT BY: Install the distributed sendmail program. FIX: Do not distribute sendmail with private copies of system source codes. Instances we find are: /usr/src/usr.lib/sendmail/aux/newaliases.c /usr/src/usr.lib/sendmail/aux/rmail.c /usr/src/usr.lib/sendmail/aux/newsyslog /usr/src/usr.lib/sendmail/aux/syslog.c /usr/src/usr.lib/sendmail/doc/syslog.3 /usr/src/usr.lib/sendmail/doc/syslog.8 /usr/src/usr.lib/sendmail/include/syslog.h /usr/src/usr.lib/sendmail/include/sysexits.h /usr/src/usr.lib/sendmail/lib/newsyslog.sh /usr/src/usr.lib/sendmail/lib/syslog.c _______________________________________________________________________________ sendmail--usr.lib rhc@ucbopal.CC ( l'Innommable ) 2 May 84 +FIX When truncated to 8 characters, the identifiers ``returntosender'' and ``returnto'' become identical. REPEAT BY: Fortunately this prevents the sendmail code from compiling on our PDPs. FIX: Replace occurances of the identifier ``returntosender'' by ``rtntosender'' in envelope.c and savemail.c. _______________________________________________________________________________ sendmail--usr.lib rhc@ucbopal.CC ( l'Innommable ) 2 May 84 +FIX The sendmail source provides a byte-moving subroutine called bmove. Most of the sendmail code uses this. The 4.2BSD C library provides a byte-moving subroutine called bcopy. Only code in headers.c invokes this. Our PDP C library does not have this subroutine. REPEAT BY: Try to make sendmail on a PDP without editing the source. FIX: Change the line in headers.c from .. bcopy (mopts, h -> h_mflags, sizeof mopts); .. to .. bmove (mopts, h -> h_mflags, sizeof mopts); _______________________________________________________________________________ sendmail--usr.lib rhc@ucbopal.CC ( l'Innommable ) 2 May 84 +FIX The sendmail source contains a byte-zero routine called clear. Several of the sendmail subprograms use it. The 4.2BSD C library contains a byte-zero routine called bzero. Several other of the sendmail subprograms use it, unfortunately, also. Our PDP C library contains no such routine. REPEAT BY: Try to make sendmail on a PDP. FIX: Change the invocations of bzero in the above files .. queue.c: bzero ((char *) & nullmailer, sizeof nullmailer); readcf.c: bzero ((char *) m, sizeof * m); sendmail.h:#define clrbitmap(map) bzero((char *) map, BITMAPBYTES) .. to .. queue.c: clear ((char *) & nullmailer, sizeof nullmailer); readcf.c: clear ((char *) m, sizeof * m); sendmail.h:#define clrbitmap(map) clear((char *) map, BITMAPBYTES) _______________________________________________________________________________ sendmail--usr.lib Liudvikas Bukys <bukys@rochester.arpa> 6 Jun 84 +FIX The myhostname() generated if DAEMON is defined has two problems: (1) it calls gethostname() incorrectly (a holdover from pre-4.1a?); (2) it assumes that hp->h_name is the same as `hostname`. REPEAT BY: Go to a machine for which `hostname` is not the first name in the /etc/hosts line. For example, on ur-seneca, whose /etc/hosts line looks like 192.5.37.83 ur-seneca seneca sen `hostname` is "seneca", not "ur-seneca". Without this fix, sendmail's $w is (seneca) and $=w is (seneca sen). With this fix, $w is (ur-seneca) and $=w is (ur-seneca seneca sen). _______________________________________________________________________________ sendmail--usr.lib Jay Lepreau <lepreau@utah-cs> 30 Jun 84 Sendmail was changed awhile ago to leave the escaping of 'From ' lines to the local mailer. Well, when it itself is the local mailer, as when going to files, I think it should do it. At least somebody's got to, or sendmail should use a different message separating convention.... REPEAT BY: Set up a mail alias to a 622 file, and mail the following to it: sendmail -t To: testfile line one From line three line four ^D Then do a Mail -f <filename> and get two messages. _______________________________________________________________________________ sendmail--usr.lib Yoon Kim <kaist!yoonkim> 13 Feb 84 When sendmail is compiled and run, a Segmentation fault error occurs. By using DBX, I narrowed down to malloc() call. It is the first call to malloc() when this error happens. (NOTE: The libsys.a problem is already fixed.) REPEAT BY: /usr/lib/sendmail (one of the any options here) i.e. /usr/lib/sendmail -q _______________________________________________________________________________ sendmail--usr.lib Web Dove <dove@sylvester> 29 Jul 84 I was trying to send mail from my lisp machine to my vax using smtp, and the vax wouldn't accept a sender address of [128.31.27.16]. _______________________________________________________________________________ sendmail/aux/syslog.c--usr.lib decvax!dartlib!steve 30 Nov 83 The periodic time mark message that syslog (the daemon) is supposed to generate only gets generated when the daemon is invoked with the debugging option, -d. REPEAT BY: Invoke the daemon as "/etc/syslog" and you get no time marks. Invoke it as "/etc/syslog -d" and you get time marks (and other stuff). FIX: In regular - non-debugging - operation, the program forks, letting the parent exit(0) and the child become the daemon. In debug mode, no fork is done. The problem is that the initial call to alarm to set up the time mark is done before the fork, so in normal operation the SIGALRM is sent to the parent, which has exited. The child daemon never gets the first signal, so there are never any time marks. The fix is just to move the alarm call down after the fork. Doing "diff new old" yields: 192a193,194 > signal(SIGALRM, domark); > alarm(MarkIntvl*60); 247,248d248 < signal(SIGALRM, domark); < alarm(MarkIntvl*60); _______________________________________________________________________________ sendmail/src/alias.c--usr.lib Tim Mann <mann@Gregorio> 4 Oct 84 +FIX If the alias database is out of date, alias.c forces Verbose mode on while printing the above warning message, then sets it back to its previous state. This has the effect of forcing the message to go out on the SMTP connection. If the site at the other end of the SMTP connection is not running sendmail, the "050" code is meaningless to it and generally causes the mail transaction to fail. REPEAT BY: Touch your /usr/lib/aliases file without running newaliases, and make sure sendmail is not configured to update it automatically. Then try to send mail from a non-sendmail site and watch it get confused. FIX: There seems to be absolutely no reason to force Verbose on in this situation, so I fixed the problem locally by removing the three lines of code in alias.c that do it. _______________________________________________________________________________ sendmail/src/collect.c--usr.lib salkind@nyu (Lou Salkind) 22 Nov 83 +FIX If sendmail encounters end of file before a newline character, it can go into an infinite loop. The reason is that the EOF condition is never explicitly checked. REPEAT BY: Certain files received with smtp will cause this. _______________________________________________________________________________ sendmail/src/collect.c--usr.lib Bill Nowicki 12 Mar 84 +FIX Recently we have been having congestion problems in our Arpanet gateway. This causes packets to be dropped, and eventually TCP connections to time out. The sendmail SMTP daemon will return a message to the sender when the TCP connection times out during transmission. It should instead just discard the partially-received message, since the sending host will send it again the next time the queue is run. This bug causes our users to get copies of their outgoing mail returned hourly until the evening when our gateway congestion disappears and the message finally gets delivered properly. REPEAT BY: Send a large message from host A to host B, (say, "nobody@B") where host B is running sendmail. After doing netstats on either host to determine that a TCP connection has been made, do a ps on host A and kill the sendmail process quickly before it completes. You will get a message back from mailer-daemon@B saying "SYSERR:unexpected close". The next time the queue is run, however, the message is successfully delivered to the user on host B. _______________________________________________________________________________ sendmail/src/collect.c--usr.lib stanonik@nprdc 2 Oct 84 +FIX If the smtp peer tcp resets while you're collect'ing the body of the message, then sendmail will loop, rereading the last line received and adding it to the df file. REPEAT BY: I don't know how to reproduce this problem, but in our case the peer did this to us every half hour for 3 days, every time they had mail for us. _______________________________________________________________________________ sendmail/src/conf.c--usr.lib rhc@ucbopal.CC ( l'Innommable ) 20 Mar 84 +FIX Sendmail has two parameters which modify the delivery behaviour, that specified by the option ``d''. These are, QueueLA, option ``x'', the load average above which messages will be left in the queue for the daemon to deliver; and RefuseLA, option ``X'', the load average above which SMTP connections will be refused. These variables are statically initialized. Their values may be changed by command argument flags, or by options in the -.cf file. Because they are statically initialized, their values are not remembered in the ``frozen'' -.fc file. (Initialized static variables are allocated in .DATA, which is not saved in, nor loaded from, the -.fc.) REPEAT BY: Edit your sendmail.cf to contain suitably low values for these options, say Ox4 OX6 and make a new ``frozen'' config-file. /usr/lib/sendmail -bz (A) At a time when the load average is above, in this case, 4, send some mail, and observe that it is delivered, rather than being left in the Queue. - or - (B) At any time, kill the sendmail daemon with some core-generating signal, say 8, and inspect the wreckage: adb will show QueueLA/ 8 RefuseLA/ 12 the compiled-in default values. FIX: Don't initialize the values of QueueLA and RefuseLA in their declaration in conf.c. - AND - Make sure you have the options Ox<number> OX<number> in your sendmail.cf file. Otherwise zero will be used. If you want to be careful, (I am not being careful here.) you might change the only two uses of these variables .../src/daemon.c: while (getla () > RefuseLA) .../src/deliver.c: if (getla() > QueueLA) to behave gracefully for values <= 0. Choose your own conception of graceful behaviour. _______________________________________________________________________________ sendmail/src/parseaddr.c--usr.lib pur-ee!Physics:crl 24 Feb 84 +FIX In rewrite(), some calls to printav() were not in an #ifded DEBUG _______________________________________________________________________________ sendmail/src/srvrsmtp.c--usr.lib Larry Peterson 12 Dec 83 +FIX We noticed that aliases were not being expanded on mail coming into the smtp server. Locally generated mail was aliases correctly thus the vast majority of aliases worked correctly since sendmail delivers to a userid even if it cannot find it in the alias table. Also, our relay machine, which is running 4.1, had an older version of sendmail running, so aliases which came in from outside of our domain were handled correctly. It was only those aliases specific to our 4.2 machine that failed. REPEAT BY: Try sending mail to 'postmaster@hostA' from hostB, given that postmaster is an alias which is known on hostA, and that hostA and hostB communicate via an smtp connection and sendmail is running as daemon on hostA. FIX: I removed the initalias(AliasFile, FALSE) function call in the function 'runinchild' which can be found in srvrsmtp.c, and replaced it by the same function call at the first of the smtp function in srvrsmtp.c (i.e. before the inifinte loop). _______________________________________________________________________________ sendmail/src/srvrsmtp.c--usr.lib pur-ee!Physics:crl 24 Feb 84 +FIX If DEBUG is defined, WizWord needs to be declared whether or not SMTP is defined. REPEAT BY: define DEBUG but not SMTP and compile. _______________________________________________________________________________ sendmail/src/{deliver,srvrsmtp}.c--usr.lib root@BERKELEY 5 Dec 83 +FIX The mail connection between Berknet and sendmail can be flakey. Incoming mail may be lost. Complaints from MAILER-DAEMON may or may not be generated. N.B. this problem is related but not identical to the `bug' fixed in version 4.21 (11/1/83) of /bin/mail. REPEAT BY: The following command should deliver the arbitrary message read from STDIN. Instead, the message is neither accepted nor returned; there are vague complaints of "Bad usage" and the message is lost. % /usr/lib/sendmail -v -T10-11 -oee -r <from> -h 1 <to> _______________________________________________________________________________ sendmail:--usr.lib Liudvikas Bukys <bukys@rochester.arpa> 8 Jun 84 +FIX Options specified on the command line are considered "sticky": they can't be overridden by later definitions on the command line or in the configuration file. (This is fine.) Unfortunately, defining a macro on the command line sets the sticky flag for 'M' (macros), so subsequent macro definitions on the command line have no effect. (This is not so good.) This is a pretty low-priority bug, since there's little reason for people to want to define more than one macro from the command line. But it would be nice if the bug disappeared from the "distribution". REPEAT BY: Stick a "$Z" someplace innocuous in sendmail.cf, like in a comment in the "Received:" line header. Mail something to yourself with /usr/lib/sendmail -oMYTESTING -oMZ123 yourself < /etc/group See what the $Z expanded into; probably nothing; should be "123". _______________________________________________________________________________ setreuid--man Spencer Thomas <thomas@utah-cs> 22 Jan 84 +FIX The manual page for setreuid and setregid claim that "only the super-user may change the real user ID (group ID) of a process". This is not true, inspection of the code in kern_prot.c shows that the real user ID may be set to the effective user ID by anybody. REPEAT BY: man setreuid FIX: Change it to read "Unprivileged users may change the real user ID to the effective user ID and vice-versa; only the super-user may make other changes." (substitute group for user in setregid.2) =Spencer _______________________________________________________________________________ sh--bin cbosgd!mark (Mark Horton) 9 Aug 84 The /bin/sh distributed with 4BSD is incredibly old - it's basically unmodified from UNIX/32V. I realize that nobody at Berkeley uses sh, I don't use it either. However, it is a good thing to put into makefiles and shell scripts, and there are people around (especially inside AT&T) who use it instead of csh, or who use the Korn shell. There have been some good things put into it, for example, /etc/profile (a feature which csh could use too.) REPEAT BY: The particular bug came up when we tried to bring up the Korn shell on a Sun, which is 4.2 but isn't a VAX. ksh tries to figure out what kind of system it's on automatically and compile itself accordingly with the right flags. This results in code in the makefile like this: if test $(FIXDATA); then do one thing; else do another thing; fi where $FIXDATA is either the null string or "1". On a VAX it's 1, so this works. But on a Sun it's null, and when make invokes sh -e, if an if fails, the shell exits instead of doing one of the branches. This terminates the make. FIX: Just get a more recent shell. If the next BSD is going to require a System V license anyway, there's no problem. Doug Gwyn (gwyn@brl) has a complete System V emulation package for 4.2BSD which includes a ported System V shell; perhaps it's easiest to get his. _______________________________________________________________________________ sh--bin jdb@s1-c 12 Mar 84 There is a serious security problem when using set-uid and/or set-gid directly-exec'able command files (i.e. those starting with "#!"). The problem is best demonstrated by example. Consider the file "/usr/local/rootdate", setuid root, containing #! /bin/sh # Run "date" as root date The following sequence is used to obtain an interactive setuid-root shell: $ ln /usr/local/rootdate /usr/tmp/- $ cd /usr/tmp $ - When the shell is run to process the command file its argv list is {"-", "-", NULL} so it assumes that it should read the standard input. It also looks for the user's ".profile" file. (The reading of ".cshrc" can be avoided by using "#! /bin/csh -f".) In 4.1BSD the problem occurs when the setuid file resides on a filesystem on which a user may create a link, e.g. linking from "/usr/local" to "/usr/tmp". In 4.2BSD the setuid file may be anywhere because a symbolic link can be used. REPEAT BY: See above. _______________________________________________________________________________ signals--sys mayo@ucbrenoir 2 Feb 84 Some tty ioctl calls hang if invoked from a procedure that was invoked as the result of a SIGCONT signal. REPEAT BY: /* * This program demonstrates a possible problem with Berkeley UNIX. * It seems that you cannot do some 'ioctl's inside of a procedure * that is invoked in response to a signal. * * To see the problem, run this program in the forground. Then stop it * using ^Z (or whatever). Now run it in the background. It should * stop on a 'tty output'. Everything is fine up to now, but now * move the program to the forground. AH HA! You are now totally * dead in the water. */ #include <stdio.h> #include <signal.h> #include <sgtty.h> struct sgttyb tx_sgtty; sigOnResume() { printf("\n<< Resume >>\n"); ioctl(fileno(stdout), TIOCSETP, (char *) &tx_sgtty); /* <-- hangs here */ printf("\n<< Done With Resume >>\n"); } main() { ioctl(fileno(stdout), TIOCGETP, (char *) &tx_sgtty); signal(SIGCONT, sigOnResume); while(1) { printf("."); fflush(stdout); sleep(1); } } _______________________________________________________________________________ sigpause--man ssc-vax!jeff@lbl-csam (Jeffrey Jongeward) 20 Jun 84 +FIX sigpause(2) states that 'sigpause ..... returning EINTR'. However, that's not right; actually, it returns -1 and sets errno to EINTR. FIX: Make indicated change to man page. _______________________________________________________________________________ sigvec.2--man lepreau@utah-cs (Jay Lepreau) 7 Nov 83 3rd param, "ovec", isn't documented at all, except for its existence & type. Is it a result param containing the old values? REPEAT BY: man sigvec _______________________________________________________________________________ socket.2--man Chris Kent <kent@BERKELEY> 10 Jun 83 There is inconsistency about the socket() sys call between the 4.1c UPM, the 4.2bsd System Manual, and the 4.2bsd IPC Primer. The UPM and IPC claim socket has 3 arguments; the SM claims 4, and neither is a proper sub-/super-set of the other. The UPM entry also references a non-existent manual page "socketopt(2)". The IPC Primer doesn't indicate any way to set options on a socket. REPEAT BY: Read the manuals. FIX: Apparently the socket() call now has three arguments; the four argument version is from 4.1a. It would also seem that the calls "getsockopt()" and "setsockopt()" exist. These all need to be documented. _______________________________________________________________________________ stand/boot.c?--sys Chris Kent <kent@BERKELEY> 15 Jun 83 +FIX The boot program doesn't understand how to interpret symbolic links at boot time. REPEAT BY: Make /vmunix a symbolic link to the actual kernel you want to run and try to boot. Boot reports "bad format" and gives up. Using symbolic links is a win if you have multiple experimental kernels around and would like to keep track of what's what, but don't want to have ps, w, uptime, rwhod, etc. be confused. _______________________________________________________________________________ stand/hp.c--sys mazama!thor (Jeff Thorson) 10 Mar 84 +FIX Up to now we have not been able to boot directly off of an Eagle drive using the standalone 'boot' from the console floppy. Boot returns the diagnostic 'not a directory'. The fix below reveals that the problem appears when an Eagle (or other non-DEC drive which must be identified by the HPSN register) resides on mba1, mba2, or mba3. REPEAT BY: B ANY boot: hp(24,0)vmunix (our Eagles reside on TR11) FIX: In /sys/stand/hp.c, replace hp_type[unit] = hpmaptype(hpaddr, i, unit); with hp_type[unit] = hpmaptype(hpaddr, i, UNITTODRIVE(unit)); That is, hpmaptype() expects the massbus unit number (0-7). Jeff Thorson Stanford University Dept. Geophysics mazama!thor _______________________________________________________________________________ stand/hp.c--sys ssc-vax!jeff@lbl-csam (Jeffrey Jongeward) 20 Jun 84 +FIX 'st' isn't set after 1st call to hpopen(). This means that disk partition offset info will be garbage, and programs (like format) that could open/close a hp-style disk more than once will fail after the first invocation. Repeat by: Run format 2 X on a drive w/o reloading from disk/casette. _______________________________________________________________________________ stdio.h--misc joe@fluke (Joe Kelsey) 26 Jul 84 +FIX Remember all of the flack recently about sign extension and getc? Whether or not you can compare (c = getc(stdin)) == EOF? Well, how about the same discussion related to putc? Yes, there are programmers who check the value returned by putc. The main problem is to detect errors indicated by _flsbuf, as in quota exceeded, or other disastrous errors. However, putc(0xff, stdout) gets sign extended (on DEC hardware, anyway) so that you can't tell it from EOF (-1). REPEAT BY: #include <stdio.h> main() { int x; if ((x = putc(0xff, stdout)) == EOF) { printf (stderr, "Error!\n"); } else { printf (stderr, "OK!\n); } } FIX: Add a mask to the putc macro in <stdio.h>. Note that I have verified this bug in VAX-11 C also! old: #define putc(x,p) (--(p)->_cnt>=0? ((int)(*(p)->_ptr++=(unsigned)(x))):_flsbuf((unsigned)(x),p)) new: #define putc(x,p) (--(p)->_cnt>=0? ((int)(*(p)->_ptr++=(unsigned)(x)))&0xff:_flsbuf((unsigned)(x),p)) This change merely makes putc operate the same as getc when filling the buffer before actually attempting to output the buffer. /Joe _______________________________________________________________________________ strings.c--ucb voder!jeff (Jeff Gilliam) 18 Oct 84 +FIX Strings has a minor bug which causes it to ignore the first 32 bytes of the data segment when run on and executable file and *not* given the '-' flag. REPEAT BY: Try 'strings /usr/ucb/strings'. You'll see output beginning with: >>> eley) 3/30/83 Usage: strings [ -a ] [ -o ] [ -# ] [ file ... ] %7D . . . Pretty clearly it is missing something at the very beginning. _______________________________________________________________________________ struct--usr.bin mazama!stew (Stewart Levin) 12 Jan 84 +FIX Using struct(1) when your login shell is csh(1) fails with the message "command trap not found". One of our people managed to lose a source file when they tried this. (Sorry, I don't have any idea how he managed that! it's not struct's fault.) REPEAT BY: Running struct under an interactive csh. FIX: add the initial line #! /bin/sh to the struct shell command file. _______________________________________________________________________________ struct--usr.bin mazama!pete (Peter Mora) 13 Aug 84 (1) struct doesnt convert computed goto's into switch blocks as it says it does. It completely ignores the computed goto and loses lines after computed goto statments. (2) struct doesnt convert if else endif blocks to ratfor, it leaves the else endif's without {}'s. REPEAT BY: write(6,*) 'enter 1 or 2' read(5,*) i goto(1,2) i 1 write(6,*) 'goto ',i goto 3 2 write(6,*) 'goto ',i 3 continue if(i.eq.1) then write(6,*) 'if ',i else write(6,*) 'if ',i endif end _______________________________________________________________________________ su.1--man jeff@BERKELEY (Jeff Stearns) 10 Dec 83 The manual page for su(1) is incomplete. For example, it does not indicate that a command argument may be executed in the style of sh -c. REPEAT BY: N/A. FIX: Include a description of the -c and -f options (are there others?) in /usr/man/man1/su.1. _______________________________________________________________________________ swapon.c--etc decvax!dartlib!steve (Steve Campbell) 28 Nov 83 +FIX When one of the syscalls returns -1, the routine hand-generates an error message. One of the arguments to printf is missing, resulting in a garbled message being printed on the console. REPEAT BY: Execute "swapon -a" manually. Since it was presumably run automatically already by /etc/rc, the manual execution will fail, since the swap devices will be busy. One good message and one bad one will be printed for each swap device in /etc/fstab. _______________________________________________________________________________ sys--sys dlw@UCBTOPAZ.CC (David L. Wasley) 4 Aug 83 There appears to be a bug whereby an interrupted open() will eat a file descriptor. This happens in 4.1a (Topaz) and 4.2 (Monet). It is a little complex to force, but ... if an open() is hung on a tty dev, and is interrupted, it returns -1. That is fine, but the file descriptor returned on the next open() will be 1 higher that it would have been before the interrupt. After N interrupts you get an error return saying "too many files open". The following program demonstrates the problem. Put it in the background and kill -INT it a number of times. David Wasley REPEAT BY: ---- #include <stdio.h> #include <signal.h> sigint() { int fd; signal(SIGINT, sigint); fprintf(stderr, "interrupt"); if ((fd = open("/dev/null", 0)) >= 0) { fprintf(stderr, " (null fd=%d)", fd); close(fd); } fputc('\n', stderr); } char *dev = "/dev/ttyp7"; main() { int fd; signal(SIGINT, sigint); for(;;) { if ((fd = open(dev, 0)) >= 0) { fprintf(stderr, "fd=%d\n"); close(fd); sleep(10); /* otherwise ... */ } else perror(dev); } } _______________________________________________________________________________ sys--sys Doug Kingston <dpk@brl-vgr> 29 Sep 83 The 4.1c kernel does not properly clear the exclusive open lock if the file that is lock is also being held open by another process which has no locks on the file. REPEAT BY: sleep 1000 < foofile # hold file open exclusively open the file and then close it try to exclusively open the file again, it will either block or return EWOULDBLOCK if you asked not to block. The following program can be used to exclusively open the file. #include <sys/file.h> main(argc, argv) int argc; char **argv; { int fd; if((fd = open(argv[1], FRDWR | FNBLOCK | FEXLOCK)) < 0) perror(argv[1]); else close(fd); } _______________________________________________________________________________ sys--sys Jeff Mogul <mogul@navajo> 13 Dec 83 mysterious file disappearance from iput() _______________________________________________________________________________ sys--sys mayo@ucbrenoir 2 Feb 84 Some tty ioctl calls hang if invoked from a procedure that was invoked as the result of a SIGCONT signal. REPEAT BY: /* * This program demonstrates a possible problem with Berkeley UNIX. * It seems that you cannot do some 'ioctl's inside of a procedure * that is invoked in response to a signal. * * To see the problem, run this program in the forground. Then stop it * using ^Z (or whatever). Now run it in the background. It should * stop on a 'tty output'. Everything is fine up to now, but now * move the program to the forground. AH HA! You are now totally * dead in the water. */ #include <stdio.h> #include <signal.h> #include <sgtty.h> struct sgttyb tx_sgtty; sigOnResume() { printf("\n<< Resume >>\n"); ioctl(fileno(stdout), TIOCSETP, (char *) &tx_sgtty); /* <-- hangs here */ printf("\n<< Done With Resume >>\n"); } main() { ioctl(fileno(stdout), TIOCGETP, (char *) &tx_sgtty); signal(SIGCONT, sigOnResume); while(1) { printf("."); fflush(stdout); sleep(1); } } _______________________________________________________________________________ sys(ipc)--sys kilianm%rpi.csnet@csnet-relay.arpa 19 Jun 84 I run a program which forks itself into two separate processes. I then try to initiate a protocol with a socket by which one process will run, then the other, etc. in strict alternation. With some combinations of sockets and socket operations, the program will run, deadlock, and when the break key is hit (control-C) the whole system freezes. The only solution is a complete reboot. The interesting point is that if the process is killed from another terminal, it termnates normally. I have encountered the problem also in programs which do not deadlock though this is a much rarer occurrence. REPEAT BY: I am including the file which causes this problem. I suggest you compile it (i.e., cc killer.c) and run it. It will most likely run a bit and then deadlock. Hit control-c to break it. Our system reliably halts. (Our system, by the way, is a VAX 11/780 running 4.2 Berkeley Unix with 4 Megabytes main core.) File which reliably halts our system: /***********************************************************************/ #include <stdio.h> #include <sys/types.h> #include <sys/socket.h> #include <errno.h> extern int errno; /* Test 10, trying to make sockets work...assume 2 processes. */ resource() { int i; int s,f; /* socket identifiers. */ char proc[30]; /* accepted socket's name. */ int proclen; /* length of accepted socket's name. */ char buffer[100]; /* message space. */ int cc; /* return code. */ s = socket(AF_UNIX,SOCK_STREAM,PF_UNSPEC); /* define resource socket. */ cc = bind(s," RESOURCE",10); /* bind name to socket. */ listen(s,1); /* only listen for 1 connection at a time. */ for (;;) { f = accept(s,proc,&proclen); /* and accept the connection. */ printf("\nAccepted %s",proc); fflush(stdout); /* NOTE TO THE DEBUGGERS! I believe the following two lines are primarily responsible for the problem. I have used a variety of combinations of sockets and they have inevitably failed when I try to close one off and possibly reopen a connection later. */ shutdown(f,2); close(f); do { cc = connect(s,proc,proclen); } while (cc < 0); shutdown(s,2); } } process1() { int reslen; /* respective lengths. */ int s,f; /* our socket number. */ int cc; char res[30]; char buffer[100]; s = socket(AF_UNIX, SOCK_STREAM, PF_UNSPEC); /* define our socket. */ bind(s," PROCESS1",10); listen(s,1); for (;;) { do { cc = connect(s," RESOURCE",10); } while (cc < 0); shutdown(s,2); f = accept(s,res,&reslen); printf("\nProcess 1 speaking..."); fflush(stdout); shutdown(f,2); close(f); } } main() { if (fork() == 0) process1(); else resource(); printf("\nWE SHOULD NEVER GET HERE."); } /***********************************************************************/ If there is updated documentation on sockets or if I am making a fundamental flaw here, please send me any information you can. Michael Kilian (kilianm@rpi) _______________________________________________________________________________ sys/init_main.c--sys Mike Braca <mjb%Brown@UDel-Relay> 3 Oct 83 +FIX The hard limit for stacksize is initialized to the max data size value instead of the max stack size value. REPEAT BY: Change the maximum data size on your machine. Reboot, log in, and look at the hard limit for your stack size. It is wrong. _______________________________________________________________________________ sys/kern_acct.c,etc/sa.c--sys watrose!root (Alex White) 2 Dec 83 +FIX Accounting records now write times out in seconds, sa still works in 60ths of seconds. Accounting entry ac_mem is incorrect as the kernel divides by SECONDS, the integrated memory usage which is in NBPG ticks. REPEAT BY: Use sa -u to see what's being printed out, its wrong. _______________________________________________________________________________ sys/kern_clock.c--sys trw-unix!gorlick 3 Jun 83 +FIX The manual page for getrusage(2) claims that the values ru_ixrss, ru_idrss, ru_isrss are in kilbyte*seconds. Inspection of sys/kern_clock.c shows that these values are kept in kilobyte*ticks where a tick occurs every 1/HZ seconds. The kernal call `getrusage' doesn't bother to average these values over 1 second intervals. If you really intend that these values be in kilobyte*seconds then it is a mistake to make them integers - they should be float. For quick commands with low memory requirements roundoff will always cause an integer value to be zero. REPEAT BY: Not applicable. FIX: Change ru_ixrss, ru_idrss, ru_isrss to be float. Keep the values internally as kilobyte*ticks but have `getrusage' transform them to kilbyte*seconds. I agree its important to insulate programs from the underlying HZ clock rate. -Michael Gorlick- TRW Redondo Beach, CA 90278 _______________________________________________________________________________ sys/kern_clock.c--sys guest@ucbarpa (Guest Account) 19 Jun 84 +FIX Time-critical code in hardware clock interrupt handler can be improved. REPEAT BY: Examine code in kern_clock.c _______________________________________________________________________________ sys/kern_clock.c--sys Chris Kent <kent@BERKELEY> 9 Jun 83 A system configured with only {cpu "VAX730"} in the config file, when compiled, results in the symbol IUR being undefined. REPEAT BY: Take GENERIC, delete the VAX780 and VAX750 lines, config it and try to compile it. FIX: A quick workaround is to define VAX780 and VAX750, but this results in a lot of needless code being included. I haven't investigated it thoroughly, but it seems that adding the definition of IUR to vax/mtpr.h, #ifdef'd on VAX730. None of the other register definitions seem germane. _______________________________________________________________________________ sys/kern_descrip.c--sys decvax!uthub!thomson (Brian Thomson) 13 Feb 84 +FIX It is possible to close a file descriptor more than once, or otherwise use it after it has been closed, and possibly after another process has reallocated it or reallocated the in-core inode it points to. REPEAT BY: If you have installed Jeff Mogul's firewall panic in closef() [ref. unix-wizards <14552@sri-arpa.UUCP> Dec 12 83] you may have already seen this. If not, then PUT IT IN FIRST!!! like so: kern_descrip.c, closef(), before (*fp->f_ops->fo_close)(fp); insert if(fp->f_count < 1) panic("closef: f_count < 1"); Then run the following program with the shell 'exec' command, such that it is the only process that has your terminal open: #include <sys/types.h> #include <setjmp.h> #include <signal.h> #include <sys/ioctl.h> jmp_buf jb; int zero; gorp() { longjmp(jb, 0); } main() { int i; for(i = 0; i < 20; i++) if(i != 1) close(i); setjmp(jb); ioctl(1, TIOCSTART, 0); ioctl(1, TIOCFLUSH, &zero); ioctl(1, TIOCSTOP, 0); write(1, "a", 1); signal(SIGALRM, gorp); alarm(1); close(1); } If all went well (so to speak) a single 'a' will print on your terminal, and your 4.2 system will have paniced. _______________________________________________________________________________ sys/kern_descrip.c--sys salkind@nyu (Lou Salkind) 27 Jan 84 +FIX If you try fcntl(fd, F_DUPFD, NOFILE), you get the error EMFILE instead of EINVAL. REPEAT BY: fcntl(fd, F_DUPFD, NOFILE); FIX: In fcntl, replace the test if (i < 0 || i > NOFILE) by if (i < 0 || i >= NOFILE) Like I said, a minor nit. _______________________________________________________________________________ sys/kern_exit.c--sys rws@mit-bold (Robert W. Scheifler) 17 Nov 83 wait() does not check for a zero rusage pointer, and does not propagate an EFAULT error that might occur in copying the rusage out. REPEAT BY: Try using an illegal rusage pointer and checking for EFAULT, or try having writable text and using a NULL rusage. FIX: In wait(), the code (void) copyout((caddr_t)&ru, (caddr_t)rup, sizeof (struct rusage)); should be changed to if (rup) u.u_error = copyout((caddr_t)&ru, (caddr_t)rup, sizeof (struct rusage)); _______________________________________________________________________________ sys/kern_resource.c--sys Mike Braca <mjb%Brown@UDel-Relay> 27 Sep 83 +FIX The csh commands "unlimit datasize" and "unlimit stacksize" fail with the "Not owner" error code. This is different from what 4.1a did, and I think 4.1a is correct -- the value should be set to the maximum allowed instead. REPEAT BY: Type "unlimit stack" to csh. _______________________________________________________________________________ sys/kern_sig.c--sys sun!shannon (Bill Shannon) 5 Sep 83 +FIX Kill can be used with signal 0 to determine if a process exists. However, if the process exists but is a different uid than the killer it returns ESRCH instead of EPERM. Returning EPERM makes it compatible with System III, as well as being more useful. REPEAT BY: However, if the process exists but is a different uid than the killer it returns ESRCH instead of EPERM. Returning EPERM makes it compatible with System III, as well as being more useful. _______________________________________________________________________________ sys/kern_sig.c--sys Mike Muuss <mike@brl-vgr> 13 Jan 84 +FIX On 4.1 and earlier UNIX systems, signal handlers had several attributes: *) After a signal was caught, the handler was reset to SIG_DFL. *) If the process was executing a (kernel) sleep() at "low" priority, and a signal was processed, the system call would abort, returning an error code (-1), with errno = u.u_error = EINTR (interupted system call). On 4.2 BSD UNIX, these two aspects of signal handling were altered (along with some other, nice improvements, which are not germane). 1) The signal handler remains "installed" until explicitly changed. 2) System calls which may (kernel) sleep() at "low" priority will be silently restarted after processing an incomming signal. The signal handler will have no idea if this is happening or not. PROBLEM. Clearly, programs written for the old style signal interface will have a fair amount of difficulty coping with difference #2 above, if they depend on signals (especially timer signals) interrupting a system call. Network software which wishes to run timouts around network reads will have to longjmp() in the signal handler, rather than being able to depend on just returning, with an EINTR to be returned from the read/write sys-call that timed out. Editors and shells will have to expect their I/O to be restarted after SIGINT, etc. (You would not believe the crud that Berkeley had to do to /bin/sh to make it still capable of re-printing $PS1 after a SIGINT (^C, etc).). Certainly, change #1 is "mostly harmless"; the number of programs which will break is minimal -- the timing windows which this change fixes were something that no mortal programmer would dare depend on. However, change #2 is truely problematic: Certainly, there are advantages to the new style signal interface, and programs which are written with this style of operation in mind should work out well. However, no matter how hard we try, few of us will be able to afford the luxury of running 4.2 BSD on *all* our machines. Those of you planning on purchasing a Cray-2 (as we are), will have to contend with System-V UNIX (at least to start with). Many other vendors will be non-4.2 BSD, and it is too late to stomp them all out (pitty, no?). And somehow, those venerable old PDP-11s just keep on refusing to quit! THEREFORE, the problem of program portability rears it's ugly head. 4.2 people (true believers) will, of course, deisre to import quality software from elsewhere ("expensive, yes, extravagant, no"), without having to re-write all the signal code. Others may wish to be able to use 4.2 code on their own system ("rotsa-ruck"). Being in the former camp, I would like to offer the following solution: REPEAT BY: Using signals. _______________________________________________________________________________ GENERAL INFORMATION ON THE 4.2 BUGLIST FROM MT XINU _________________________________________________________________ --IMPORTANT DISCLAIMERS-- Material in this announcement and the accompanying reports has been edited and organized by MT XINU as a service to the UNIX community on a non-profit, non-commercial basis. MT XINU MAKES NO WARRANTY, EXPRESSED OR IMPLIED, ABOUT THE ACCURACY, COMPLETENESS, OR FITNESS FOR USE FOR ANY PURPOSE OF ANY MATERIAL INCLUDED IN THESE REPORTS. MT XINU welcomes comments in writing about the contents of these reports via uucp or US mail. MT XINU cannot, however, accept telephone calls or enter into telephone conversations about this material. _________________________________________________________________ Legal difficulties which have delayed the distribution of 4.2bsd buglist summaries by MT XINU have been resolved and three versions of the buglist are now available. The current buglist has been derived from reports submitted to 4bsd-bugs@BERKELEY (not from reports submitted only to net.bugs.4bsd, for example). Reports are integrated into the buglist as they are received, so that any distributions are current to within a week or so. Buglists now being distributed are essentially "raw". No judgment has been passed as to whether the submitted bug is real or not or whether it has been fixed. Only minimal edit- ing has been done to produce a manageable list. Reports which are complaints (rather than bug reports) have been eliminated; obscenities and content-free flames have been eliminated; and duplicates have been combined. The result- ing collection contains over 500 bugs. Three versions of the buglist are now ready for distribu- tion: 2-Liners: Two lines per bug, including a concise description, the affected module, the submittor. Approximately 55K bytes, it is being distributed to net.sources con- currently with this announcement. All-but-Source: All material, except that all but the most inocuous of source material has been removed to meet AT&T license restrictions. Nearly a mega-byte, this will be distributed to net.sources in several 50K byte pieces later this week. A paper listing or mag tape is also available, see below. Please note that local usenet size restrictions may prevent large files from being received and/or retransmitted. MT XINU will not dump this material on the net a second time; if your site has not received material of interest to you within a reasonable time, please send for a paper or tape copy. All-with-Source (FOR SOURCE LICENSEES ONLY): 4.2 licensees who also have a suitable AT&T source license can obtain a tape containing all the material, including proposed source fixes where such were submit- ted. Once again, MT XINU has not evaluated, tested or passed judgment on proposed fixes; all we have done is organ- ize the collection and eliminate obvious irrelevancies and duplications. A free paper copy of the All-but-Source list can be obtained by sending mail to: MT XINU 739 Allston Way Berkeley CA 94710 attn: buglist or electronic mail to: ucbvax!mtxinu!buglist (Be sure to include your US mail address!) For a tape, send a check for $110 or a purchase order for $150 to cover MT XINU's costs to the address given above (California orders add sales tax). For the All-with-Source list, mail us a request for the details of license verifica- tion at either of the above addresses.