vance@mtxinu.UUCP (Vance Vaughan) (11/07/84)
4.2 BUGLIST ABSTRACTS from MT XINU, part 3 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...
f77--usr.bin jerry@ucbopal.CC (Jerry Berkman) 29 Feb 84
In double precision, if you raise an expression x to a variable
power y, and if the expression contains a power and at least
another operation, then Fortran "may" return y**y instead of x**y.
REPEAT BY:
Compile and run following program in which both z and z2 should
be identical.
c implicit real*8 (a-z)
data x/2.0d0/, y/3.0d0/
c
z = (x**2.d0+1.d0)**(-y)
anum = x**2.d0+1.d0
power = -y
z2 = anum**power
print *,' x,y,anum,power,z,z2 =',x,y,anum,power,z,z2
end
_______________________________________________________________________________
f77--usr.bin sdcsvax!sdchema!donn 8 Jun 84 +FIX
This bug only strikes when the optimizer is OFF. If a DO
loop variable is used for other purposes in a routine and in
particular is used in the loop initialization, limit or
increment at the same time it is used as the loop variable, the
parameter containing the loop variable will appear to be
garbage. This bug was originally sent to me by Robert Elz
of the University of Melbourne.
REPEAT BY:
Compile the following program with 'f77 -S' (examples are
courtesy of Robert Elz):
----------------------------------------------------------------
k = 1
i = 1
do 10 k = k, 10
i = i + k
10 continue
print i
end
----------------------------------------------------------------
In the assembly language output we see that the register is
initialized from itself, instead of the memory version of the
loop variable:
----------------------------------------------------------------
movl $1,{k}(r11)
movl $1,{i}(r11)
movl r10,r10 <<<<<<<<<<<
cmpl r10,$10
jgtr L16
L17:
movl r10,{k}(r11)
addl3 r10,{i}(r11),r0
movl r0,{i}(r11)
L15:
incl r10
cmpl r10,$10
jleq L17
L16:
movl r10,{k}(r11)
clrl -104(fp)
movl $6,-100(fp)
movl {i}(r11),-92(fp)
addl3 $-104,fp,r0
pushl r0
calls $1,_s_wsfe
calls $0,_e_wsfe
L14:
ret
----------------------------------------------------------------
_______________________________________________________________________________
f77--usr.bin jerry@ucbopal.CC (Jerry Berkman) 7 Dec 83
When my declarations are in an 'include' file,
I get:
'Compiler error: Impossible tag 0 in cpexpr'
if instead I put the declarations in the .f file, I get syntax error!
I should get the syntax error whether the declarations are in
the script or not.
REPEAT BY:
Run the following script:
#
cat << 'EOT' >! before
subroutine tabit( text, fldlen, okv )
character text(fldlen)
integer fldlen
logical okv(1)
'EOT'
cat << 'EOT' >! incs
include 'outbuf.com'
include 'params.com'
'EOT'
cat << 'EOT' >! after
integer blanks
if(blanks.gt.1) then
outptr = outptr - blanks + 1
outbuf(outptr) = tab
endif
end
'EOT'
cat << 'EOT' >! outbuf.com
character outbuf(80), tab
integer outptr
common /outbc/ outbuf, tab
common /outbi/ outptr
'EOT'
cat << 'EOT' >! params.com
character eol, tab
parameter ( eol=char(0), tab='\t' )
'EOT'
cat before incs after >! prog1.f
f77 prog1.f
cat before outbuf.com params.com after >! prog2.f
f77 prog2.f
rm before after incs outbuf.com params.com prog1.f prog2.f
_______________________________________________________________________________
f77--usr.bin sdcsvax!sdchema!donn 6 Apr 84 +FIX
This bug is the same as the one reported by trq@astrovax.UUCP
with the subject 'problem with mixed-mode in f77'. Basically
it randomly applies to f77 programs that have an expression in
which a value of a type other than INTEGER is multiplied by the
constant 0. Admittedly few real programs explicitly multiply
by zero -- the main sources of examples are programs which have
PARAMETER variables that are set to zero.
REPEAT BY:
Put the following program in a file named constbug.f:
----------------------------------------------------------------
program constbug
integer iwrblk
iwrblk = 1 + 0 * 1.0
print *, iwrblk
stop
end
----------------------------------------------------------------
If you compile this program with the optimizer on, the compiler
says:
----------------------------------------------------------------
constbug.f:
MAIN constbug:
Compiler error line 5 of constbug.f: Impossible type 0 in routine mkconv
compiler error.
----------------------------------------------------------------
If you compile the program with the optimizer off, it prints '0'.
(What you would expect it to print is '1'.)
_______________________________________________________________________________
f77--usr.bin allegra!astrovax!trq (Thomas R. Quinn) 18 Mar 84
Assigning an integer to the sum of an integer and "0" times "iparam"
where the value of "iparam" is defined in a parameter statement results
in the integer being assigned the value "0".
REPEAT BY:
Compile and run the following program under f77.
parameter(IRED = 256)
iwrblk = 10 + 0*IRED
print *,iwrblk
end
The program will print "0" instead of the correct value "10". Note
that the statement
print *, 10 + 0*IRED
will print the correct value.
_______________________________________________________________________________
f77--usr.bin jerry@ucbopal.CC (Jerry Berkman) 28 Feb 84
Compilation error when subroutine and statement function
have dummy argument of same name but different dimension.
REPEAT BY:
Try to compile the following:
real vec(3)
data vec / 2.0, 3.0, 4.0 /
call sub(vec)
end
subroutine sub( x )
real x(3)
sumsq(x) = x*x
sum = 0
do 10 i=1,3
sum = sum + sumsq(x(i))
10 continue
print *, sum
end
_______________________________________________________________________________
f77--usr.bin leres@ucbarpa (Craig Leres) 6 Nov 83
The f77 compiler chokes on certain kinds of input, only when the -O
flag is used.
REPEAT BY:
The following subroutine:
subroutine fail(str, i, j)
integer str(100)
integer i, j
str(min0(i,j)) = 0
return
end
when compiled with -O, produces the error message:
Compiler error line 4 of a.f: Impossible tag 4 in routine frtemp
_______________________________________________________________________________
f77/src/f2--usr.bin ucsfcgl!ucsfcgl!gregc (Greg Couch) 3 Nov 83
The FORTRAN optomizer messes up under some strange conditions.
See example program below.
REPEAT BY:
Compile the program below with and without optomization. The version
without optomization will print out eight lines, while the version
with optomization never stops.
C exercise FORTRAN 77 optomization bug
C
integer i, j, x, y, xorg, xdd
data xorg, xdd /10, 2/
do 10 i = 1, xdd
do 10 j = 1, 2
x = xorg + (i - 1) * xdd
call moveto(x, y)
call moveto(x + 3, y)
10 continue
end
subroutine moveto(x, y)
integer x,y
print *, x, y
return
end
_______________________________________________________________________________
f77/src/f77pass1/exec.c--usr.bin sdcsvax!sdchema!donn () 23 Nov 83 +FIX
This problem occurs in the f77 compiler supplied on a tape
made on 8/23/83.
In f77 DO loops, a variable loop limit is squirreled away in a
local variable so that it cannot be altered during the course
of the loop. (This is because the standard says that DO loop
initializations, limits and increments are only evaluated once,
when the loop is first entered.) Unfortunately the loop limit
is saved in a temporary variable which may be reallocated when
subroutine arguments are evaluated in the loop. (Since f77
requires that arguments be passed to subroutines by reference
rather than by value, these temporaries are used to give an
address to the output of an expression.) This leads to loops
which are executed an unpredictable number of times, clearly a
major error. The problem is mitigated slightly by the fact
that unless the loop is complicated, the loop limit quantity
will migrate into register from its place on the stack, and
after this it is safe from being clobbered.
REPEAT BY:
Copy the following f77 program into the file bug1.f:
--------------------------------------------------------------
program bug1
integer i, j, k, l, m, n, o
j = 2
k = 3
l = 4
m = 5
n = 6
o = 7
do 20 i=1,k
j = j + l
l = i + j
j = l * j
l = j - l
m = l * i
n = l * m
o = m - l
m = o + 3
n = o / m
o = j + n
call dummy( i+1, j+2, l+3 )
write(unit=6,fmt=10) i
10 format('Loop pass ', i3)
20 continue
stop
end
subroutine dummy( a, b, c )
integer a, b, c
return
end
--------------------------------------------------------------
Notice that the expected output is:
Loop pass 1
Loop pass 2
Loop pass 3
In fact this program goes into an infinite loop, counting up to
infinity. To see why, compile again using the command:
f77 -d14 -S -O bug1.f
F77pass1 will print the debugging comment that offset -4 is being
reused. If you look at the assembler output file bug1.s, you
should see that the loop limit is stored at -4(fp), and that the
call to dummy() clobbers -4(fp) with the value of i+1... hence
the infinite loop.
_______________________________________________________________________________
f77/src/f77pass1/regalloc.c--usr.bin sdcsvax!sdchema!donn () 23 Nov 83 +FIX
This problem occurs in the f77 compiler supplied on a tape
made on 8/23/83.
While compiling a program with 'f77 -O ...' that contains
a computed GOTO, f77 stops with a 'Termination code 11' or
'Termination code 132' and a core dump of f77pass1 is left
behind. This only occurs with a certain very large program
which I have that is generated with a ratfor-like pre-
processor and contains zillions of gotos and DO loops.
REPEAT BY:
The program that causes this is much too large to send by
mail or news, but it is available on request. I have tried
replicating the problem with smaller programs, to no avail.
The program contains the line:
GOTO(16,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15),COMBO
_______________________________________________________________________________
f77/src/f77pass1/regalloc.c--usr.bin sdcsvax!sdchema!donn 23 Nov 83 +FIX
This problem occurs in the f77 compiler supplied on a tape
made on 8/23/83.
The f77 compiler generates code which contains instructions
like 'movl r10,r10' when optimizing embedded loops. Since
these instructions are easy to find, it seems strange that they
are missed; and in fact the reason for this appears to be that
the register optimization code in alreg() is buggy.
REPEAT BY:
Copy out the following f77 program and call it 'bug3.f':
----------------------------------------------------------------------
program bug3
integer i, j, k, l, m, n
i = 1
j = 2
k = 3
l = 4
m = 5
n = 6
do 20 i = 1, 10
do 10 j = 1, 10
k = m * j
l = n * i
m = i * k
n = j * l
10 continue
20 continue
stop
end
----------------------------------------------------------------------
Compile the program with 'f77 -O -S -c bug3.f'. This program will
have code in it that looks like this:
----------------------------------------------------------------------
movl $1,v.2-v.1(r11)
movl $2,v.3-v.1(r11)
movl $3,v.4-v.1(r11)
movl $4,v.5-v.1(r11)
movl $5,v.6-v.1(r11)
movl $6,v.7-v.1(r11)
movl v.3-v.1(r11),r10
movl v.2-v.1(r11),r9
movl v.4-v.1(r11),r8
movl v.5-v.1(r11),r7
movl v.6-v.1(r11),r6
movl $1,r9
L17:
movl r10,r10 /*** Redundant ***/
movl $1,r10
L22:
mull3 r10,r6,r8
mull3 r9,v.7-v.1(r11),r7
mull3 r8,r9,r6
mull3 r7,r10,v.7-v.1(r11)
aobleq $10,r10,L22
movl r6,r6 /*** Redundant ***/
movl r7,r7 /*** Redundant ***/
movl r8,r8 /*** Redundant ***/
movl r10,r10 /*** Redundant ***/
acbl $10,$1,r9,L17
movl r6,v.6-v.1(r11)
movl r7,v.5-v.1(r11)
movl r8,v.4-v.1(r11)
movl r9,v.2-v.1(r11)
movl r10,v.3-v.1(r11)
pushl $0
pushal L25
calls $2,_s_stop
ret
----------------------------------------------------------------------
(I have prettied up the output considerably here...) The
redundant moves are marked by comments.
_______________________________________________________________________________
f77/src/f77pass1/regalloc.c--usr.bin sdcsvax!sdchema!donn 27 Nov 83 +FIX
This problem occurs in the f77 compiler supplied on a tape
made on 8/23/83.
The new f77 compiler will put INTEGERs in register but not
REALs even though the VAX allows REAL (4-byte floating point)
values to appear in general registers. This adds unnecessary
overhead to programs which do lots of computations with REAL
values (that is to say, virtually all typical f77 programs).
REPEAT BY:
Clip out the following f77 program and put it in a file named
bug4.f:
--------------------------------------------------------------------
program bug4
integer i
real a, b, c
a = 2.0
b = 1.0
c = 0.999
do 100 i = 1, 1000000
a = (a + b) * c
100 continue
stop
end
--------------------------------------------------------------------
Compile this program with the command 'f77 -S -O -c bug4.f'.
The assembler output shows that REAL variables are not put in
register while integer values are. The following is a
pretty-printed version of the assembler file, where variables
of the form 'v.4-v.1(r11)' are written '{variable}' and
addresses of constants of the form 'L25' are written
'{constant}' (you can get the pretty-printer by sending mail to
me asking for it):
--------------------------------------------------------------------
.globl _MAIN_
.set LF1,0
_MAIN_:
.word LWM1
subl2 $LF1,sp
jmp L12
L13:
movl {0x4100},{a}
movl {0x4080},{b}
movl {0xbe77407f},{c}
movl {i},r10
movl $1,r10
L17:
addf3 {b},{a},r0
mulf3 {c},r0,{a}
aobleq $1000000,r10,L17
movl r10,{i}
pushl $0
pushal {00,00}
calls $2,_s_stop
ret
.align 1
_bug4_:
.word LWM1
L12:
moval v.1,r11
jmp L13
--------------------------------------------------------------------
Notice that the INTEGER variable 'i' is put in register 10 but
the only time that a register is used for a REAL is when it is
necessary to hold the intermediate result of an expression
computation; ordinary REAL variables are not assigned registers
when DO loops are optimized.
_______________________________________________________________________________
fed--ucb hpda!hpdsd!edmund (Ed Trujillo) 7 Mar 84
fed only returns an error message once invoked.
Apparently, the signal routine as called in fed bombs with
a SIGSYS errno. fed aborts even before it can process its
argument list.
REPEAT BY:
Type in the command with or without an argument.
% fed <font.file>
Bad system call (core dumped)
FIX:
Move the signal(SIGSYS, onsig) from the bottom of the signal
calls to the top. This apparently fixed the problem as it
works for my hp2648.
17a18
> signal(SIGSYS, onsig);
23d23
< signal(SIGSYS, onsig);
_______________________________________________________________________________
find--usr.bin decvax!popvax!neilr 9 May 84 +FIX
When using find with long file names, segmentation fault occurs.
No one bothered to change buffer from 200 higher.
REPEAT BY:
cd /tmp
cp /dev/null aaaaaaaaaaa {more than 200 a's}
find /tmp -print
core dump will occur
FIX:
12c12
< char Pathname[200];
---
> char Pathname[MAXPATHLEN + 1];
_______________________________________________________________________________
find--man donn@utah-cs (Donn Seeley) 5 Oct 84 +FIX
The C-shell eats braces, and the syntax for the '-exec' feature
of 'find' uses braces to indicate the position to interpolate a
filename. Novice users of the C-shell frequently forget to
quote braces when using 'find', and this problem is exaggerated
because the manual page uses the Bourne shell for its
examples.
REPEAT BY:
The instigation for this is a Usenet posting by wall@berkeley
which demonstrates confusion about braces and 'find'. The
message-ID on the article is <2343@ucbvax.ARPA>; I won't
reproduce it here.
FIX:
I suggest the following changes:
----------------------------------------------------------------
> The end of the command must be punctuated by an escaped
> semicolon.
< A command argument `{}' is replaced by the
< current pathname.
---
> The end of the command must be punctuated by a semicolon.
> A command argument `{}' is replaced by the current pathname.
> Some shells treat braces and semicolons specially,
> so it is a good idea
> to protect them by escaping or quoting them.
----------------------------------------------------------------
Then there is the example:
----------------------------------------------------------------
< \-atime +7 \-exec rm {} \\;
---
> \-atime +7 \-exec rm "{}" ";"
----------------------------------------------------------------
The syntax of 'find' leaves much to be desired,
Donn Seeley University of Utah CS Dept donn@utah-cs.arpa
40 46' 6"N 111 50' 34"W (801) 581-5668 decvax!utah-cs!donn
_______________________________________________________________________________
find--usr.bin gillies@mit-comet (Donald Gillies) 13 Jun 84
I believe that find will not work when you attempt to find
files from ABOVE a soft-linked directory. I haven't looked
carefully at the code for find, but I tried two identical finds on
(1) a real directory, and (2) a soft link to the same directory.
Just ECHOing the filename worked for (1), but not
for (2). The find commands looked like:
REPEAT BY:
ln -s realdir softdir
# works fine, slowly -- prints answers:
find realdir \( -name '*.h' \) -newer datefile -echo {} \;
# prints nothing, terminates quickly:
find softdir \( -name '*.h' \) -newer datefile -echo {} \;
FIX:
find realdir \( -name '*.h' \) -newer datefile -echo {} \;
# prints nothing, terminates quickly:
_______________________________________________________________________________
find.c--usr.bin sjk@sri-spam (Scott J. Kramer) 5 Dec 83 +FIX
The "find" program doesn't recognize sockets in the UNIX domain.
REPEAT BY:
Try "find ... -type s ..." on a directory with sockets.
_______________________________________________________________________________
fp/fpMain.l--ucb baden@ucbmonet (Scott Baden) 9 Oct 83 +FIX
There are two system calls, in the file 'fpMain.l', that are
incompatible with some UNIX systems, resulting in core being
dumped. The calls are both '(syscall 13)'.
REPEAT BY:
simply run fp and type in any application for evaluation.
+ : <3 4> will suffice.
FIX:
The two calls should be changed to '(sys:time)' (no argument).
_______________________________________________________________________________
fsck--etc Dave Rosenthal <cmuitca!dave@cmu-cs-vlsi.arpa> 28 Sep 83 +FIX
Fsck should remove sockets during preen mode. When
the system has crashed because Unix mode sockets
have been used (see another bug/fix report), the
system comes up single user because fsck is nervous
about socket inodes. This problem has been observed
on 4.1c Vax systems and SUN 0.3/0.4 systems.
These fixes were developed with support from IBM.
REPEAT BY:
Attempt almost any operation with a Unix domain
socket, and observe the system trying to re-boot.
The test programs in my submission about Unix
domain sockets will cause the problem.
_______________________________________________________________________________
fsck.c--etc chris@maryland (Chris Torek) 22 Oct 84 +FIX
Under certain uncommon conditions, fsck will die with a
segmentation fault instead of repairing a damaged file
system. The reason is that in order to calculate the number
of disk blocks used by any particular inode, one must round
up. This is done by the ``howmany'' macro as follows:
#define howmany(x, y) (((x)+((y)-1))/(y))
if x is sufficiently large, then adding y-1 may make it
negative. This is precisely what happens to fsck.
REPEAT BY:
Create a file system error such that an inode has a di_size
of 0x7fffffff (or something very close to but not greater
than that), and run ``fsck'' on that file system.
_______________________________________________________________________________
ftp--ucb Mike Muuss <mike@brl-vgr> 8 Sep 83
Date: 1 Sep 1983 16:03:33 EDT
From: Edward A. Cain <cain@edn-unix>
Subject: early findings
To: mike@brl
Speaking of FTP. No matter which brl-vgr address I open the command connection
to, when I do a RETR your server FTP opens a connection on the Class C
address. Got that? If I open the FTP command connection to 128.20.1.1, your
server FTP will open the data connection from 192.5.21.6. The port numbers
are right, but my user ftp will of course be looking for something from
the 128.20.1.1. That explains why I had such bad luck with ftp a few
days ago.
More some other day.
Ed Cain
REPEAT BY:
Doing the above test with a machine with 2 interfaces to
separate networks.
_______________________________________________________________________________
ftp--ucb jbn@FORD-WDL1 26 May 83
I think I understand why others are able to communicate with your FTP
while we are not. The TCP passive open mechanism is usually used to
allow servers to wait for a connection attempt. In such cases, the
``foreign-socket'' is entirely unspecified. In the FTP case, though,
the ``foreign-socket'' is fully specified, including the ``foreign-port''
in the passive TCP open call. I suspect that some TCP implementations
do not require a matchup of ``foreign-port'' on passive open operations.
The spec, though, reads ``A passive open may have either a fully
specified foreign socket to wait for a particular connection or an
unspecified foreign socket to wait for any call.''. Clearly FTP uses
the second case, and thus TCP should insist on all 4 parameters (foreign
port, foreign host, local port, and local host) matching exactly before
establishing the connection.
John Nagle
Ford Aerospace and Communications
_______________________________________________________________________________
ftp--ucb Chris Torek <chris%umcp-cs.csnet@csnet-relay.arpa> 2 Mar 84
I tell our FTP to do a remote cwd to "pub"; I receive the message
vv
550 pub: No such file or directory
^^
Judging by the message, I suspect someone's not trimming a blank
somewhere.
By the way, after I sent this I did a list, then tried to do
something else, and got a "not responding: timeout" type message.
This could be in the BBN FTP though; there are rumours of bugs
in the "port" command. Does 4.2 FTP use the funny port stuff?
REPEAT BY:
FTP (I am doing it from a 4.1+BBN TCP/IP system) to a 4.2 system
and try to "cwd" to a legal directory.
_______________________________________________________________________________
ftp/cmds.c--ucb Jeff Mogul <mogul@coyote> 20 Mar 84 +FIX
The syntax for the mls and mdir commands is
mdir remote-pathname local-filename
Unless local-filename is "-", ftp (cryptically and
uncharacteristicly) asks for confirmation (presumably,
meaning "do you really want to write on this file?"
However, if you type "n" or "N", it goes ahead and
writes the file, while if you type anything else (a positive
response) it gives up.
Essentially the same bug causes a problem with a "globbed"
local-filename that doesn't match any extant file; ftp will
instead create a file with the metacharacters in the filename.
REPEAT BY:
% ftp localhost
... login ...
ftp> mls /etc /tmp/foo
local-file /tmp/foo? y
ftp>
ftp> mls /etc /tmp/foo
local-file /tmp/foo? n
mls ac? ...
.
.
.
ftp> mls /etc/ /tmp/This*does*not*exist
local-file /tmp/This*does*not*exist? n
.
.
.
ftp> bye
% ls /tmp/This*does*not*exist
This*does*not*exist
%
_______________________________________________________________________________
ftp/getpass.c--ucb rws@mit-bold (Robert W. Scheifler) 31 Jan 84 +FIX
User ftp truncates passwords to 8 characters, which loses
completely when talking to non-Unix sites.
REPEAT BY:
ftp to a TOPS-20, for example, and try to login to an
account with a long password.
FIX:
Change
static char pbuf[9];
to
static char pbuf[51];
and
if (p < &pbuf[8])
to
if (p < &pbuf[50])
or some other suitably large values. (Geez, C+Unix=blech.)
_______________________________________________________________________________
ftpd.c--etc Christopher A Kent <cak@Purdue.ARPA> 13 Jan 84 +FIX
The FTP daemon doesn't properly log anonymous logins in
/usr/adm/wtmp because the chroot to /usr/ftp is done before wtmp is
opened; thus the open always fails. My previous fix to this was not
wonderful, because while it correctly record logins, it never recorded
logouts. This version does both. I also changed logging to be done via
syslog(3), and now log the ident supplied by anonymous users as well as
all connections.
REPEAT BY:
ftp to localhost, log in as ftp, quit, and do a last. No record.
_______________________________________________________________________________
ftpd/ftpd.c--etc Christopher A Kent <cak@Purdue.ARPA> 25 Mar 84 +FIX
On multi-homed hosts, ftpd won't always work because the code to
anchor the reply socket is incorrect; the getsockname() call
has a bad argument, thus the filled in address is always 0.
REPEAT BY:
ftp to a multi-homed host on the same net as yours, but specify
the alternate address as the host to connect to.
_______________________________________________________________________________
ftpd/ftpd.c--etc bloom@ucbcory (Jim Bloom) 20 Sep 83 +FIX
It is possible under ftp to defeat the checking for null
passwords in /etc/passwd. This allows users to login
without a password to access the system.
REPEAT BY:
ftp to a machine with a null passwd for some user (cory won't
work). Give the user name. When asked for a passwd, respond
with "@". It will log one onto the machine as that user.
_______________________________________________________________________________
getgroups.2--man Mike Braca <mjb%Brown@UDel-Relay> 27 Sep 83 +FIX
The man page for getgroups says the max number of groups that
will be returned is given by NGRPS in <sys/param.h>,
but it's really NGROUPS.
REPEAT BY:
N/A
FIX:
s/NGRPS/NGROUPS
_______________________________________________________________________________
getgroups.2--man lepreau@utah-cs (Jay Lepreau) 27 Oct 83 +FIX
getgroups(2) returns the actual number of grps returned in gidset,
and its first parameter is an int, the max number of grps to
return. (This happens to agree with the "4.2 system manual",
section 1.1.3.) It returns -1 and EINVAL if the max number of
grps specified is not large enough to hold all of them. The max number
is NGROUPS from param.h. The manual page, however, says that:
1. it returns 0 on success, -1 on failure.
2. its first parameter is an int *, and that it is value-result.
3. the only possible error is EFAULT.
4. the max number is NGRPS.
5. "see also" refers to initgroups(3), should be 3x.
The setgroups(2) man page also refers to NGRPS instead of NGROUPS.
REPEAT BY:
Inspection of sys/kern_prot.c, or run this pgm:
int gidset[20];
int ngrps = 10;
int ret, i;
main()
{
ret = getgroups(ngrps, gidset);
printf("ret = %d, ngrps = %d\ngidset:", ret, ngrps);
for (i = 0; i < 20; i++)
printf(" %d", gidset[i]);
printf("\n");
}
_______________________________________________________________________________
getitimer.2--man Chris Kent <kent@BERKELEY> 24 Jul 83 +FIX
This manual page is awful. The timer value description is
out of date (itimer_{value,interva;} don't exist!), and
the difference between a "value" and an "interval" isn't
explained.
REPEAT BY:
Read the page.
FIX:
Apparently, the name of the structure elements changed...
Also, it seems that the "interval" is the automatically
reloaded value of the timer, and the "value" is the time to
wait before firing once. This should be made clear.
----------
_______________________________________________________________________________
getrlimit.2--man Mike Braca <mjb%Brown@UDel-Relay> 3 Oct 83 +FIX
The man page for getrlimit(2) says the name for infinity is
RLIMIT_INFINITY, but <resource.h> has RLIM_INFINITY. Personally
I prefer RLIMIT for consistency, but what the hell.
REPEAT BY:
N/A
FIX:
s/RLIMIT_INFINITY/RLIM_INFINITY
_______________________________________________________________________________
gettable.c--etc jsq@ut-sally.ARPA (John Quarterman) 12 Feb 84 +FIX
The method recommended by the DARPA Internet Network Information
Center for updating host tables from the master on sri-nic
is to fetch the version number regularly and then get the
whole table when the version changes. Gettable only allows
fetching the whole table, not the version number.
REPEAT BY:
Look at the gettable man page or the source.
Can't repeat something that can't be done.
_______________________________________________________________________________
gettable.c--etc salkind@nyu (Lou Salkind) 17 Nov 83 +FIX
Gettable uses the nicname service instead of the hostname
service to get the NIC host table.
REPEAT BY:
Typing the command.
_______________________________________________________________________________
getty/subr.c--etc decvax!popvax!neilr 15 May 84 +FIX
Even if the ck flag was set in gettytab, the CRTKIL flag
was never being set in the local mode word.
Looks as though someone forgot to put the code in, since
it is just like to ce and cb code (crterase and crtbs)
REPEAT BY:
make a gettytab entry with a :ck: entry
login
stty everything
crtkill won't be set
_______________________________________________________________________________
groups.2--man ralph 23 Mar 83 +FIX
On the arpavax, the manual page for groups(2) refers to setgrp(2)
in its SEE ALSO section; this should read setgroup(2).
_______________________________________________________________________________
h/ioctl.h--sys <cmuitca!jag@cmu-cs-h.arpa@cmu-cs-h.arpa> 15 Jul 84 +FIX
The code in tty_pty.c that handles TIOCREMOTE expects the ioctl to be
passed one argument: the address of the REMOTE on/off value. ioctl.h
incorrectly defines TIOCREMOTE as:
#define TIOCREMOTE _IO(t, 105) /* remote input editing */
This indicates no arguments, which leads to unpredictable behaviour.
_______________________________________________________________________________
h/un.h--sys spgggm@ucbopal.CC (Greg Minshall) 31 Jan 84 +FIX
Doing a bind() in the Unix domain, if we pass the size of
the sockaddr_un structure, we get EINVAL (on our system; on
ucbarpa it seems to give EMSGSIZE). This is because the Vax
C compiler says that the size is 112 bytes, and therefore
sys/sys/uipc_userreq.c in unp_bind() doesn't have room to
stick on a null termination. Really, sockaddr_un seems to
be 111 bytes long, but apparently the compiler says "well, it's
going to take me 112 bytes, since the next data structure will
start at an even byte address".
REPEAT BY:
#include <sys/un.h>
(more includes)
int
hintSet(path)
char *path; /* path name for hint */
{
int s, length, diddle, savedError;
long mypid;
struct sockaddr_un foo;
s = socket(AF_UNIX, SOCK_DGRAM, 0);
if (s == -1) {
perror("hintSet: socket");
exit(1);
}
length = strlen(path);
if (length > sizeof foo.sun_path)
length = sizeof foo.sun_path;
strncpy(foo.sun_path, path, length);
if (bind(s, &foo, (sizeof foo)-1) == -1) {
if ( ((savedError = errno) == EADDRINUSE) &&
(open(path, O_RDONLY) == -1) &&
(errno == EOPNOTSUPP) &&
(unlink(path) != -1) &&
(bind(s, &foo, (sizeof foo)-1) != -1) )
;
else {
errno = savedError;
perror("hintSet: bind");
exit(1);
}
}
return(s);
}
FIX:
One of two things: Change the C compiler (but, I'm not sure that
would be a fix, or a failure). Better yet, make
sun_path[108] instead of sun_path[109].
_______________________________________________________________________________
h/{}.h--sys ihnp4!ihesa!bob (Bob Van Valzah) 18 Jul 84 +FIX
Using userid and groupid greater than 32767 causes a host of
problems in the kernel. The most recent problem is that
a file cannot be access by its group permission bits when its
gid is greater than 32767.
REPEAT BY:
Make yourself a member of group 33000.
as root:
chgrp 33000 FileYouDontOwn
chmod 770 FileYouDontOwn
as you:
touch FileYouDontOwn
You will be denied access to the file because the kernel is
looking at the other protection bits instead of the group bits.
FIX:
In the .h files listed below, instert "unisgned" in the
declaration of the given fields.
acct.h ac_udi, ac_gid
inode.h ic_uid, ic_gid
proc.h p_uid
quota.h q_uid, dq_uid
stat.h st_uid, st_gid
user.h u_uid, u_gid, u_groups
Bob Van Valzah
Consultant to AT&T Bell Labs (312) 979-3632 ..ihnp4!ihesa!bob
Employed by Lachman Assoc. (312) 986-8840 ..ihnp4!laidbak!bob
_______________________________________________________________________________
ideas--sys raphael@wisc-crys.arpa (Raphael Finkel) 22 May 84
When Unix crashes, it may be a while since the last sync. File that have
recently been written to may not have information out yet. The superblock
may be wrong. However, when Unix starts up again, it can determine the
contents of core at the time of crash and save those contents in a file.
I recommend that the equivalent of a sync be done (maybe optionally) during
this time to try to bring the disk to a consistent state without losing
information.
REPEAT BY:
The situation that is most irksome is leaving the editor a few seconds
before the crash; the file often ends up empty after the crash.
_______________________________________________________________________________
ifconfig.c--etc sun!pugs (Tom Lyon) 1 Nov 83 +FIX
1) Sense of arp flag is inverted.
2) State of arp flag is not reported
3) flags are trashed when hostname is followed by flag
REPEAT BY:
Hard to notice problems.
Run 'ifconfig arp' and then attempt to communicate
with a host which requires arp.
_______________________________________________________________________________
ifconfig.c--etc lepreau@utah-cs (Jay Lepreau) 5 Nov 83 +FIX
Even with Tom Lyons' fixes, it did not work when setting
the address of an interface the 1st time and also setting
a flag. Problem was that the SIFADDR ioctl can change the
value of the flags, e.g., RUNNING and BROADCAST, but a later
option setting will use the original value of flags.
REPEAT BY:
E.g., in /etc/rc.local, for an interlan, do:
/etc/ifconfig il0 `hostname` -arp
You should get an interface that's UP but not broadcast or running,
which breaks a number of things (like rwhod).
_______________________________________________________________________________
init.c--etc allegra!astrovax!wls Jun 25 83 +FIX
There is a race condition in /etc/init for 4.1 BSD. If a HUP signal is
sent to init, causing it to reread /etc/ttys, and at the same time
someone logs out, it is possible for init to lose track of the fact
that the logout occurred. If this happens no new process is created
for that port and the port is effectively dead. In this state
/etc/utmp is not updated so that the person still appears on the
list of users logged in, but without a process. The condition can be
cleared by disabling the port, then reenabling it.
The bug is in the fact that merge() is called and the branch out of
the loop is taken without checking that the pid returned by the wait
might be valid. On a loaded system it is quite possible for one of
init's children to die in the window between the HUP signal and init's
response to it.
We have a version of uucp that uses the same ports for dialing in and
dialing out. It regularly turns the dialin ports on and off, exposing
the existence of this bug.
REPEAT BY:
Send a HUP to init and at the same time kill one of init's children
that is a process group header (not an orphan process). If the timing
is just right init will not know of the child's death. This is more
likely to occur on a heavily loaded system.
_______________________________________________________________________________
init.c--etc Richard Johnson <raj@uci-750a> 9 Aug 84 +FIX
The init program uses the assumption that if after running getty
that fork returns in less than 1 minute, then getty failed. This
is not always true.
REPEAT BY:
Pick a terminal and keep logging in and back out again making sure
you never stay logged in for more than 1 minute. After about 5 times
of logging in and out again, the console will produce the bogus
message "init: getty failing; sleeping...".
_______________________________________________________________________________
ioinit(3F)--usr.lib gvax.bill@Cornell.ARPA (Bill Nesheim) 25 Jun 84 +FIX
Fortran programs using "ioinit" won't load
REPEAT BY:
Call ioinit from a fortran program. Watch it die.
FIX:
run the command ar tv /usr/lib/libI77.a
you will note that rather than ioinit.o, ioinit.f is
included.
recompile and re-archive libI77
_______________________________________________________________________________
iostat--usr.bin George R. Cross 6 May 84
After the system has been running a few days, a call to iostat results in
a report with a negative percentage in the ni column. Here is an example:
tty ra0 ra1 ra2 cpu
tin tout bps tps msps bps tps msps bps tps msps us ni sy id
3 43 9 3 0.0 0 0 0.0 0 0 0.0 44-47 6 0
REPEAT BY:
Only occurs after system is running for a few days. Works ok right
after reboot. If iostat is given interval argument, like iostat 10,
first line is garbled as above, following lines are ok.
_______________________________________________________________________________
iostat.c--usr.bin mazama!stew (Stewart Levin) 22 Mar 84 +FIX
After we employed the kgclock (adapted to our ancient AR11) driver
to gather I/O and profiling samples, some of the numbers given by
iostat were off by a factor of 10. As we were running the external
clock at 10HZ and the internal clock runs at 100HZ, it was easy to
find the cause. iostat (and vmstat) were not reading the "phz"
variable from the kernel's namelist and simply assuming it identical
to the kernel's "hz" variable.
REPEAT BY:
Collecting samples using an external clock set to other than 100HZ.
FIX:
Read both "phz" and "hz" from /dev/kmem and use the former sampling
rate if it is nonzero. Be aware, however, that it may not have been
calibrated correctly. kgclock supposedly counts the number of external
clock interupts occurring over a four second interval as measured using
the system clock. However when we looked at phz (using adb) it was 3
not 10! We cured the problem by explicitly initializing all relevant
variables to zero on entry to the kgstart() routine. I can't say for
sure why it fixed the bug, but either an unitialized variable was
the culprit or the system modifies its idea of the time between the
kgprobe() and kgstart() calls.
_______________________________________________________________________________
last.c--ucb Jay Lepreau <lepreau@utah-cs> 25 Nov 83 +FIX
When remotely executed, last does not print out the response
to SIGQUIT until something else forces it out.
(QUIT prints out the "current" date in the wtmp file
and continues.)
A misfeature: I think your deletion in the 4.2 release version (changed
from the prerelease version) of the "net-login-time" for pseudo-
user "reboot" is a mistake-- that gives useful information,
(average uptime), as mentioned in the man page.
Repeat-By
arpa last foo; ^\
FIX:
Add an fflush(stdout); right after the printf in onintr().
For "reboot"-- add that code back in again.
_______________________________________________________________________________
lastcomm.c--ucb sun!Jskud 29 Nov 83 +FIX
lastcomm does not format partial blocks
uses explicit bn * DEV_BSIZE vice dbtob(bn) macro
REPEAT BY:
just invoke lastcomm, and you will note that very recent
commands do not show up -- in fact, up to the last 16.
_______________________________________________________________________________
ld--bin decvax!ubc-vision!sfucmpt!kurn (Andrew Kurn) 28 Feb 84 +FIX
When asked to print load map, ld prints only those files which
contributed code to the load module. There is no way to get a listing of
those modules which merely define storage (COMMON).
REPEAT BY:
Create an archive containing at least one module which does nothing
but define a block of named storage. The loader will not list it.
_______________________________________________________________________________
learn--bin wjcheng@ucbernie (Wunjei J. Cheng) 18 Dec 83
1. Can not specify the user directory.
2. Can not specify the subject.
REPEAT BY:
1. "learn -tmpdir C 1.1f" does NOT work, but
"learn C 1.1f" does work.
2. After type "learn -tmpdir", you will see some
of the guiding message missing and also cannot
specify the subject.
_______________________________________________________________________________
learn/copy.c--usr.bin ihnp4!cmcl2!rna!dan 18 Feb 84 +FIX
1) Typing EOT to learn causes learn to loop on error from stdin.
2) learn scripts files, eqn, vi cannot startup at all.
REPEAT BY:
(above)
_______________________________________________________________________________
leave.c--ucb Support Group (agent: Richard Johnson) 31 Jul 84 +FIX
Leave doesn't work if you specify the time using the "+" syntax.
When the bug causing this is fixed, it gives a bogus error message.
REPEAT BY:
Type "leave +1". You'll never see the warning.
_______________________________________________________________________________
lex--usr.bin joe@fluke (Joe Kelsey) 14 Aug 84 +FIX
Lines longer than 200 characters overflow lex line buffers,
wreaking havoc in other data structures.
REPEAT BY:
Take the pathalias software as distributed and try out the
new uucp maps. Notice how things fall apart very quickly.
FIX:
Replace the #define YYLMAX 200 in function chd1 in header.c
with #define YYLMAX BUFSIZ. This will allow a more reasonable
line limit and try to prevent overflowing buffers. Grumble about
sloppy programmers who can't use big buffers or dynamically
allow for larger limits.
_______________________________________________________________________________
lex--usr.bin mazama!stew (Stewart Levin) 2 Feb 84 +FIX
The following lex program -
/* Convert , to ,^ inside equation text */
/* Assumes delim $$ for embedded equations */
%Start INEQN
%%
^".EQ"[.]* { ECHO; BEGIN INEQN; } /* enter equation text */
^".EN"[.]* { ECHO; BEGIN 0; } /* exit equation text */
<INEQN>"$" { ECHO; BEGIN 0; } /* exit equation text */
<INEQN>"," { ECHO; putchar('^'); } /* change , to ,^ */
"$" { ECHO; BEGIN INEQN; } /* enter equation text */
%%
gave the unexpected result of turning the line
.EQ (10a,b)
into
.EQ (10a,^b)
The reason is that a period is not considered a special character
inside brackets. The lex manual (page LEX-7) gives an example
of [.\n]+ which they say would match the whole text. Not so -
this only matches repetitions of the two characters period and newline.
The lex program that works is
/* Convert , to ,^ inside equation text */
/* Assumes delim $$ for embedded equations */
%Start INEQN
%%
^".EQ".* { ECHO; BEGIN INEQN; } /* enter equation text */
^".EN".* { ECHO; BEGIN 0; } /* exit equation text */
<INEQN>"$" { ECHO; BEGIN 0; } /* exit equation text */
<INEQN>"," { ECHO; putchar('^'); } /* change , to ,^ */
"$" { ECHO; BEGIN INEQN; } /* enter equation text */
%%
REPEAT BY:
Running the above examples.
FIX:
Correct the example in the lex documentation.
_______________________________________________________________________________
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.