4.2 BUGLIST, part 7 of 10
Vance Vaughan
vance at mtxinu.UUCP
Sat Nov 10 03:02:18 AEST 1984
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 at 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 at 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 at 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 at 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 at 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 at ucbdali (Rick Mcgeer) 24 Jul 84
sendmail does not accept the following address, which is valid:
"gladd tom at lll-mfe.arpa"
instead it sends:
gladd.tom at lll-mfe.arpa
REPEAT BY:
send mail to user gladd tom at lll-mfe.arpa, or to the postmaster at that
site, "provan don"@lll-mfe.arpa
_______________________________________________________________________________
sendmail--usr.lib root at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at navajo> 13 Dec 83
mysterious file disappearance from iput()
_______________________________________________________________________________
sys--sys mayo at 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 at 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 at rpi)
_______________________________________________________________________________
sys/init_main.c--sys Mike Braca <mjb%Brown at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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.
More information about the Comp.sources.unix
mailing list