4.2 BUGLIST, Part 6 of 10
Vance Vaughan
vance at mtxinu.UUCP
Fri Nov 9 10:59:06 AEST 1984
4.2 BUGLIST ABSTRACTS from MT XINU, part 6 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...
newfs.c--etc mtxinu!ed (Ed Gould) 17 Apr 84 +FIX
newfs fails to pass error status returned from mkfs.
REPEAT BY:
newfs /dev/idonthave eagle
FIX:
change
if(status = system(cmd))
exit(status);
to
if(status = system(cmd))
exit(status >> 8);
_______________________________________________________________________________
nroff--usr.bin alex at cca-unix (Alexis Layton) 4 May 84 +FIX
Nroff will occasionally change the permission of the current directory
to be unexecutable by everyone. (In fact the directory permission
becomes the default tty device permission.) What is happening is that
ttyname() is being used twice and the earlier value is being re-used
after the second call to ttyname. (Note we have modified ttyname(3)
on our system slightly, so this next assertion may not apply:)
ttyname() returns a static char *; and the second call almost always
returns NULL but also re-initializes the static buffer to "".
This has the effect of doing a chmod("", original-tty-name), which
(Viola!) clobbers the current directory permission.
REPEAT BY:
Unfortunately, I am not quite clear on how to repeat this reliably.
I believe you must run nroff with standard output redirected but
not standard input or error. This is a hypothesis only.
FIX:
I can't provide good diffs because we changed a few other things in
our nroff; but here is a description of the fix. Basically we are
strcpy'ing the first value of ttyname. To the beginning of the
file add a buffer
char ttynamebuf[128];
after
char *ttyp;
Then, in init2(), after the three lines of if statement inwhich
ttyname() plays a major role, add
if (ttyp)
ttyp = strcpy(ttynamebuf, ttyp);
This should fix the problem.
_______________________________________________________________________________
nroff/n1.c,n4.c--usr.bin smoot at ut-sally.ARPA 9 Jan 84 +FIX
The System V mm macros use a get af type format request '\g'
which is missing in the V7 nroff. For sites with S5 licenses
running 4.2BSD this is annoying and causes the mm macros to fail.
Also defined number registers have their format set to '0'. This
should be '1' for the mm macros to work properly.
REPEAT BY:
nroff -rN10
\gN
_______________________________________________________________________________
pascal--ucb serge at ucbcory (Serge Granik) 14 Nov 83
The following program illustrates a bug in the code generator of pc.
REPEAT BY:
program errors(output);
var
prtflags : set of 'a'..'z';
begin
prtflags := ['e'];
if (prtflags * ['a', 'e'] = ['e']) then
writeln('true')
else
writeln('false');
end.
When run through pi;px the output is 'true' (correct).
When run through pc;a.out the output is 'false' (***error***).
_______________________________________________________________________________
pascal/pi--ucb emory!km (Ken Mandelberg) 3 Feb 84
Pix blows up on the second real number read from stdin.
More precisely, the first real read following the read
of a real number entered with a decimal point will fail.
REPEAT BY:
Script started on Fri Feb 3 18:36:32 1984
% cat test2.p
program cnvx(input,output);
var
x:real;
begin
readln(x); writeln(x);
readln(x); writeln(x);
end.
% pix test2.p
Execution begins...
1.1
1.10000000000000e+00
1.2
standard input: Bad data found on real read
Program error
Do you wish to enter the debugger? n
Error in "cnvx"+2 near line 7.
Execution terminated abnormally.
3 statements executed in 0000.80 seconds cpu time.
%
script done on Fri Feb 3 18:37:43 1984
FIX:
Unknown. Pc does not have the same bug, so it
can be used when real reads are needed.
_______________________________________________________________________________
pascal/pxp/rval.c--ucb Jeff Mogul <mogul at coyote> 28 Mar 84 +FIX
pxp in pretty-printer mode will remove a necessary
parentheses around an expression preceeded by a unary minus.
This can cause problems when you later try to compile code
run through pxp.
REPEAT BY:
run this program through pxp:
program pxpbug(output);
begin
writeln(-(3-4));
end.
The resulting program will print -7, instead of 1.
_______________________________________________________________________________
pascal/src/hash.c--ucb Jeff Mogul <mogul at Coyote> 6 Apr 84 +FIX
Unless run in "standard" (-s) mode, the Berkeley Pascal
language processors (pi, pc, pxp) demand lower-case-only
keywords. In standard mode, case in the source files is
ignored. This leads to a dilemma for people trying to
compile code written originally for other compilers, since
if they want to use any extensions, they cannot use standard
mode.
REPEAT BY:
Try running this program through pi, pc, or pxp (don't use -s):
PROGRAM Test(output);
BEGIN
writeln('hello')
END.
_______________________________________________________________________________
pascal/utilities/config.c--ucb ogcvax!root.tektronix Oct 7 83
On the 4.2 distribution tape (tape was made at UCB on
Oct 2 1983) the file /usr/src/ucb/pascal/utilities/config.c
is a symbolic link to ../pi/config.c, but that file does
not exist. There is no file config.c anywhere in
/usr/src/ucb/pascal.
---------------------------------------
Bruce Jerrick
Oregon Graduate Center
(503) 645-1121 ex. 355
CSNet: bruce at Oregon-Grad
UUCP: ...teklabs!ogcvax!bruce
_______________________________________________________________________________
pascal/utilities/pc.c--ucb raphael at wisc-crys 14 Feb 84
I suggest a new predeclared procedure in Pascal, implemented both for
pc and for pi/px, called 'writeheap'. It gives a list of all heap objects
that have been allocated but not deallocated. It would be nice to list
with each one the line number of the 'new' that allocated the object.
It is not necessary to print a reference count or an indication of whether
the object is reachable.
This feature is intended for debugging programs that make use of the heap.
A common error is to forget to deallocate an object. The programmer would
call 'writeheap' at the end of the program, and if any heap objects are
listed, the programmer could find out why the objects were not deallocated
and take steps to remedy the problem.
REPEAT BY:
This is not a problem.
_______________________________________________________________________________
pc--ucb weemba at ucbbrahms (Matthew P. Wiener) 8 Sep 84
pi,pc, etc. will look for files in #include statements in the current
directory, unlike cc which has a -I option.
REPEAT BY:
create two files in a directory dir:
p.p: program hi(output); i.i: writeln('Hi there')
begin
#include "i.i"
end.
% pi p.p
works fine, but
% cd ..
% pi dir/p.p
doesn't.
Apparently-To: 4bsd-bugs at BERKELEY
_______________________________________________________________________________
pc--usr.lib mls at wisc-crys.arpa (Michael Scott) 28 May 84 +FIX
The built-in function 'remove' in Berkeley pascal (pc) works fine
for constant strings:
remove ('foo');
It also works fine for null-terminated string variables:
var s : alfa;
...
s := 'foo';
s[4] := chr(0);
remove (s);
It does not work if s is left blank-padded and not null-terminated.
REPEAT BY:
% touch foo
% cat >! rm.p
program rm;
var s : alfa;
begin
s := 'foo';
remove (s);
end.
% pc rm.p
% a.out
_______________________________________________________________________________
pcc--lib elvy at harvard.ARPA (Marc Elvy) 3 Jul 84
The "asm" statement is handled incorrectly in both the 4.1BSD and
4.2BSD C compilers. An "asm" after an "if" is placed within the
range of the "if"; braces make no difference.
REPEAT BY:
Compile the following C program. This was prepared explicitly for
illustration purposes (which is why R11 is assumed), so please do
not waste your time hassling me about the philosophical problems
with "asm" statements.
main ()
{
register int flag = 0;
if (flag == 1)
flag = 0;
asm ("movl $666, r11");
}
The relevant portion of the assembly language produced follows.
clrl r11
cmpl r11,$1
jneq L16
clrl r11
movl $666, r11 /* Here is the "asm" statement. */
L16:
ret
Note that the "movl" should be AFTER the label, not before.
Unfortunately, I have not discovered why this is done, but I
suspect that the asm statement is dumped before the if statement
is completely processed.
Marc
_______________________________________________________________________________
pcc/table.c--lib Jeff Mogul <mogul at coyote> 2 Apr 84 +FIX
When pcc (the C compiler) generates code to compare a float
and a double, it first converts the float to a double but
doesn't realize that this takes two registers, not one.
If more than one temporary register is in use while evaluating
such a comparision, one of the register may be trashed.
This bug applies to 4.1BSD and probably all earlier Vax pcc
versions.
REPEAT BY:
compile this C program:
double dd[] = { 0.0, 2.0 };
float ff[] = { 0.0, 1.0 };
int i = 1;
main(){
if( ff[i] >= dd[i] ) printf( "wrong\n" );
}
If you run it, it will print "wrong" because the
code that is generated (cf. cc -S) for the comparison
is:
movl _i,r0
movl _i,r1
cvtfd _ff[r0],r0 # trashes r1
cmpd r0,_dd[r1] # index is random
jlss L19
_______________________________________________________________________________
pr--bin Kevin C Smallwood <kcs at Purdue.ARPA> 6 Jul 84 +FIX
Using pr(1) with the "-t" option does not produce the results I
would have thought it should. Essentially, "pr -t foo.c" is
the same as "cat foo.c". What I believe should happen is that
the output stream should be a multiple of page-length lines.
That is, at the end of printing a file, the output stream should
be padded with blank lines until the "last" logical page is filled.
By "last", I am also referring to the partial, logical page
between pr'ing several files (eg., pr -t foo.c bar.c). In this
situation, the last page of foo.c should be padded with blank lines
so that bar.c starts at the top of the next logical page. Is
this how others see the semantics of "pr -t foo.c"?
REPEAT BY:
Just try "pr -t foo.c" and compare it to "cat foo.c"; they will be
the same. No blank line padding will be at the end of the output
stream.
_______________________________________________________________________________
print.sh--ucb cbosgd!mark (Mark Horton) 1 Jul 83
I tried to print out a directory of files, and got the diagnostic
lpr: cannot create /usr/spool/lpd/df 274cbosgd
cat -v showed that the "space" in the file name was a meta
null, e.g. 0200.
REPEAT BY:
The directory in question was the Usenet directory as posted to
net.news.map on July 1. The file names in question were:
aus.nsw eur.d usa.fl usa.mo usa.ri
can.ab eur.dk usa.ga usa.ms usa.sc
can.bc eur.f usa.hi usa.mt usa.sd
can.mb eur.gb usa.ia usa.nc usa.te
can.nb eur.gb.pss usa.id usa.nd usa.tx
can.nf eur.nl usa.il usa.ne usa.ut
can.ns eur.s usa.in usa.nh usa.va
can.nt usa.ak usa.ka usa.nj usa.vt
can.on usa.al usa.ky usa.nm usa.wa
can.pe usa.ar usa.la usa.nv usa.wi
can.pq usa.az usa.ma usa.ny usa.wv
can.sk usa.ca usa.md usa.oh usa.wy
can.yt usa.co usa.me usa.ok
eur.b usa.ct usa.mi usa.or
eur.ch usa.de usa.mn usa.pa
The command that caused the problem was
print *
Also, typing
print * |& cat -v
was enlightening.
The command
pr -f * | lpr
worked, producing about a file of about 150K bytes. Just printing
one file:
print aus*
worked fine. /usr/ucb/lpr is suid root, /usr/spool/lpd is 755 owned
by root (as distributed). Presumably it's the meta-null that the
kernel doesn't like. There was a hefty pause between issuing the
command and getting the diagnostic, of about 10 seconds, as if it
were reading all the files.
_______________________________________________________________________________
prof.c--usr.bin ralph (Ralph Campbell) 25 Apr 83 +FIX
prof generates labels for all global symbols when generating
a plot, regardless of the setting of the "-z" flag.
REPEAT BY:
Running prof -v on a program that never calls a particular
function; especially on a program with a very large number
of global symbols.
_______________________________________________________________________________
ps.c--bin genji at ucbopal.CC (Genji Schmeder) 15 Oct 84 +FIX
MAXTTYS == 256 is not always large enough,
not so much because there this many actual ttys,
but because ps classifies rather broadly when
looking for ttys in /dev directory. Diagnostic
is "tty table overflow". Problem doesnt occur
when U option creates /etc/psdatabase since
more precise classification is used.
REPEAT BY:
Find a system with 300 or so devices in /dev
and no /etc/psdatabase file. Then just say "ps".
FIX:
#define MAXTTYS 512
_______________________________________________________________________________
pstat.c--etc chris at maryland (Chris Torek) 14 Sep 84
The pstat -t code appears to have a bug in its handling of systems
without ptys. The code reads
pty:
if (nl[SPTY].n_type == 0)
goto pty;
which is obviously wrong. Soemthing else I just noticed is
that it assumes 32 ptys, which is wrong on our system.
Also, the code is ridiculous! Why duplicate the read-and-print
loop for every device? Suggested fix is to have a routine to
find the ``nXX'' and ``XX'' (XX==device) labels, read them and
the tty structures,
printf("%d %s line%s\n", n, devname, n == 1 ? "" : "s"),
and then print out the interesting info.
_______________________________________________________________________________
pstat.c,ps.c--etc watmath!arwhite (Alex White) 17 Feb 84 +FIX
ps -k vmunix.xx vmcore.xx
pstat -k vmunix.xx vmcore.xx
both blow up with garbage.
REPEAT BY:
Procedure to repeat the problem.
_______________________________________________________________________________
putc--usr.lib ralph at ucbarpa (Ralph Campbell) 31 Jul 84
the macro putc does not return EOF if you attempt to write
onto a read only file.
REPEAT BY:
main()
{
FILE *fp;
fp = fopen("/dev/null","r");
if ( putc('A',fp) != EOF )
printf("Putc don't work\n");
}
_______________________________________________________________________________
pxp--ucb jacques (05006000) 8 May 84
pxp when reformating pascal programs, removes the declaration
of the arguments to a function which is itself passed as an argument.
For example, given the sample pascal program below, doing:
% pi test.p
works fine. But doing:
% pxp test.p > new.p
% pi new.p
to reformat the program and compiling the newly formatted program
produces fatal errors. Here is the test program:
REPEAT BY:
program test(input, output);
function xxxx(tmp: integer; function zzzz(zzz: integer): integer): integer;
{ function zzzz is a dummy function used by xxxx but otherwise
undefined inside the xxxx function.
Here is the problem ---> pxp removes (zzz: integer) }
begin
xxxx := tmp+zzzz(tmp)
end;
function yyyy(tmp : integer): integer;
{ here is the actual function that I will pass to function xxxx
when I call xxxx in the main program
this function simply returns the square of the argument }
begin
yyyy := tmp*tmp
end;
{ here is the main program calling function xxxx, note that I
pass the function yyyy as an argument to xxxx
the answer should be: 3 + 3*3 = 12 }
begin
writeln(xxxx(3,yyyy))
end.
_______________________________________________________________________________
rcp--ucb mayo at UCBCALDER 10 Aug 83
'rcp mach:fromfile tofile' screws up if fromfile contains any
'*' pattern matching characters.
The result is a 'protocol screwup: expected control record' message.
REPEAT BY:
Log onto ucbcalder and try 'rcp ucbkim:/bla\* .'
_______________________________________________________________________________
rcp.c--ucb rws at mit-bold (Robert W. Scheifler) 3 Jan 84 +FIX
rcp (version 4.8) doesn't work for 3rd party copies.
In forking rsh it uses -L instead of -l, and uses the wrong
user name at the destination.
Even with this fix, I don't think this form of copy has the
right semantics in terms of who must be equivalent to whom.
I would have thought that if I could do
rcp host1.name1:foo /tmp/foo
rcp /tmp/foo host2.name2:foo
then I should be able to do
rcp host1.name1:foo host2.name2:foo
but that isn't the case. The current implementation requires
that name1 at host1 (not me) be in the .rhosts of name2 at host2.
REPEAT BY:
Try doing one.
_______________________________________________________________________________
rcp.c--ucb mlgray at ucbcory (Mary L. Gray) 11 Feb 84 +FIX
rcp creates file in / when user lacks permission
REPEAT BY:
rcp -r machine.person:dir /temp
FIX:
Change line 481 from:
} else if (mkdir(nambuf, mode) < 0)
to:
} else if (mkdir(nambuf, mode) != 0)
or change mkdir to return negative error codes only.
The source access was courtesy of ucsfcgl!gregc.
The bug fix is courtesy of ucsfcgl!gregc and mlgray at ucbcory.
_______________________________________________________________________________
rcs/{ci.c,rcsgen.c}--new lepreau at utah-cs (Jay Lepreau) 19 Oct 83 +FIX
4.2 bsd fixed a bug in stdio: now EOF "sticks", so if
you once get EOF and you want to read more from the terminal
you must explicitly clear EOF first.
REPEAT BY:
Try to ci more than one file at a time, or try "ci -k" on
some existing working files with no RCS file.
ci foo bar
ci -k foo
It doesn't let you enter anything in the second log msg.
_______________________________________________________________________________
reboot.8--man cbosgd!mark (Mark Horton) 19 Jun 83
The boot procedure for the 750 does not document what the various
positions of the "reboot action" and "boot device" switches mean.
From experience, boot device D seems to boot from disk, and one
reboot action causes a normal reboot; another causes it to attempt
to dump core to disk first. But I can't find this documented
anywhere. Savecore(8) and reboot(8) (which apparently have not
been updated since 4.1, according to their dates) claim a copy is
taken automatically from the end of the swap area, no mention of
the role of the switches in this. Presumably there is some similar
control on a 730 and 780.
In a related problem, whenever I try to take a dump, I get messages
about dumping to a negative location on a decice. I suspect what
is happening is that the dump routine has the size of the paging
area hardwired in instead of taking it from *swap.o. We have
cut the size of the paging area in half (having found that most of
it is never used) and this is the only ill effect so far.
2 or 3 times I've found that the system has "gone away" and doesn't
respond, although it will continue to echo characters. It appears
to be related to the disk - any given port goes away after you ask
it to touch the disk. But I can't reproduce it and so far haven't
gotten any dumps. (The problem is rare enough not to be a problem,
and it might even be a hardware problem here.)
REPEAT BY:
n/a
_______________________________________________________________________________
refer--usr.bin sdcsvax!sdccsu3!cons at Nosc (Consultants) 11 Jul 84 +FIX
When refer is run with the -l flag it builds citation labels
from reference data fields, usually author and date, e.g.
Jones1984. If two cited references result in the same label,
refer attempts to disambiguate the labels by appending a
character. The appended character should be a lowercase
letter (a, b, c, ...). Instead a control character
(^A, ^B, ^C, ...) is appended.
REPEAT BY:
Create a reference database containing two references
which have the same author (%A) and date (%D); create
a document which cites the two references;
refer -l document
Notice that the label constructed for the second cited
reference ends with ^A.
FIX:
Modify the routine keylet in refer5.c. Add code to
adjust the value of x before the return:
if (x == 0) /* The last reference to use this signal
** was put out plain; this reference
** needs disambiguating character 'a'.
*/
x = 'a'-1;
return(labc[nref] = x+1);
Comment:
There is a related problem. Currently the disambiguating
characters are issued on the first pass through the document.
If a duplicate label situation arises, the first label has no
character appended. This results in sets of labels such as
Jones1984, Jones1984a, Jones1984b instead of
Jones1984a, Jones1984b, Jones1984c. If the references are
printed as a sorted list (-s) the labels are usually out of
order.
It would be preferable to issue the characters after all
citations have been seen, and after any sorting has been done
(in a manner similar to that in which numeric labels are now
adjusted after sorting).
If we implemented this change what are the chances that it
would be incorporated in future distributions.
Rick Accurso
Computer Center UCSD
ucbvax!sdcsvax!sdccsu3!accurso
_______________________________________________________________________________
refer--usr.bin solomon at wisc-crys.arpa 29 May 84 +FIX
When refer is called with the -s flag (sort references) and the -e flag
(delay the bibliography to the end) and the document contains multiple
references to the same document, the bibliography may not be completely
sorted, and some of the citations in the text may listed as [0].
REPEAT BY:
refer -e -s test
Where "test" is the following file:
Here are some references.
to yacc
.[
yacc
.]
a forward
.[
foreword
.]
another yacc
.[
yacc
.]
and a preface to unix
.[
preface
.]
references:
.[
$LIST$
.]
_______________________________________________________________________________
refer--usr.bin mls at wisc-crys (Michael Scott) 17 Jan 84 +FIX
If the -s option is specified, and if an inverted index exists
for the references file, and if a particular source is cited
more than once, then the second and subsequent citations
interfere with the citations that follow THEM. The interfered-
with citations are given footnote number zero and are listed at
the END of the bibliography, regardless of where they belong in
the proper sorted order.
REPEAT BY:
refer -p references paper
Where 'references' contains the following:
%A R. Finkel
%A M. Solomon
%A D. DeWitt
%A L. Landweber
%T The Charlotte Distributed Operating System:
Part IV of The First Report on the Crystal Project
%R Technical Report
%I University of Wisconsin - Madison
%D 1983
%A R. E. Strom
%A S. Yemini
%T NIL: An Integrated Language and System for Distributed Programming
%V 18
%N 6
%P 73-82
%J Proceedings of the SIGPLAN '83 Symposium on Programming Language Issues
in Software Systems
%C San Francisco
%D 27-29 June 1983
%O \fIACM SIGPLAN Notices\fP, June 1983
%A N. Wirth
%T Modula: a Language for Modular Multiprogramming
%J Software--Practice and Experience
%V 7
%D 1977
%P 3-35
And 'paper' contains the following:
First reference to Charlotte:
.[
charlotte first crystal report
.]
Another reference:
.[
wirth modula multiprogramming
.]
Second reference to Charlotte:
.[
charlotte first crystal report
.]
Reference that gets screwed up:
.[
strom yemini nil distributed system
.]
References:
.[
$LIST$
.]
_______________________________________________________________________________
refer--usr.bin mazama!stew (Stewart Levin) 11 Feb 84 +FIX
When refer is told to generate a unique suffix character
for interpolated signals, the suffix characters generated
are the sequence \000, \001, \002, etc. rather than
'a', 'b', 'c', ...
REPEAT BY:
"refer -kL" with a "%L Author, 1980-" in the reference list.
FIX:
Change the declaration "x = -1;" in subroutine keylet() of
file refer5.c to "x = 'a' -1;" instead.
Admittedly this really only patches an option of refer that
doesn't operate in a useful way anyhow. What is really wanted
is for refer to interpolate the additional letter only when
more than one reference by the same authors and date is included
in the document and then to follow that up with the same change
in the stored, sorted reference list. This is, of course, what
most journals insist on.
Also, a good deal more flexibility is desirable in formatting
interpolated signals so that, for example, references of the
form "Smith (1980) says ..." and of the form "some critics
(Smith, 1980; Jones, 1982) ..." can appear in the same document
without post-refer editing.
_______________________________________________________________________________
refer--usr.bin George R. Cross 5 Jul 84
refer will not find some bibliography entries if the bibliography file
is not in the same directory. Moving the paper usiing the bibliography
to the same directory as as the bibliography will clear the references. The
references are cited as [0] and appear in the list of references at the end
however.
REPEAT BY:
can supply a sample file that has this problem.
_______________________________________________________________________________
refer--usr.bin mls at wisc-crys (Michael Scott) 17 Jan 84 +FIX
When refer is asked to sort references on the basis of author
name (-sA option) it should consider %Q fields as well as %A.
REPEAT BY:
This is a well-known bug (mentioned in user's manual).
_______________________________________________________________________________
refer/addbib.c--usr.bin salkind at nyu (Lou Salkind) 17 Nov 83 +FIX
addbib asks you to enter an abstract, terminated by a ^D.
You terminate with a ^D and the program goes into an infinite
loop.
REPEAT BY:
Try it and see (oh, the fun you will have)!
FIX:
Here is one possible solution. Clear the EOF indicator and check
whether there is more input. A simple
diff addbib.c.dist addbib.c
follows:
170c170,172
< fgets(line, BUFSIZ, stdin);
---
> clearerr(stdin);
> if (fgets(line, BUFSIZ, stdin) == NULL)
> return;
_______________________________________________________________________________
renice--man ouster at ucbkim (John Ousterhout) 11 Sep 83 +FIX
The order of the arguments in the renice(8) man page
is backwards.
REPEAT BY:
Type "man renice"
FIX:
Change the order of the arguments in the man page to
"renice priority pid".
_______________________________________________________________________________
restor--etc bukys at Rochester.ARPA 5 Jul 83 +FIX
It is possible for a dump(8) tape to have an inconsistent idea
of the length of a file. (It happened to me!) Then restor(8)
may find a data block when it is expecting a header block. As
the header parsing routine does a consistency check, this
should not be much of a problem. However, in one case the code
does not check the value returned by the header parsing
routine, and treats the data block as a very strange header
block. If this happens while reading directory files from the
tape, it will think it has reached the end of the directory
dump, but will not have built up the entire directory
structure. (This is what happened to me.) The subsequent
restoration will skip the files without corresponding directory
information.
REPEAT BY:
I suppose I could send you the tape. The problem was that the
inode said that the file was 1056 bytes (2 blocks) long, but
the c_addr array said there were 3 data blocks (there were).
Furthermore, this file (a directory!) had a hole. The most
obvious warning was 150 "missing directory entry" messages.
The second most obvious warning was that very few files were
getting restored.
_______________________________________________________________________________
restor/restor.c--etc ogcvax!root.tektronix at Rand-Relay Oct 7 83
The command "restor ts 3" extracts files, instead of just
giving a listing. It is the "s" key that causes this behavior;
manually skipping to file 3 ("mt fsf 2") followed by "restor t"
does not extract files, which is correct.
REPEAT BY:
Get into an empty directory -- Warning: this will extract files
from the tape into this directory. With something like the 4.2
distribution tape mounted (because it has a dump(8) file on
file 3) give the command "restor ts 3". You will get a listing
as expected, but it will also extract the files into the current
directory.
---------------------------------------
Bruce Jerrick
Oregon Graduate Center
(503) 645-1121 ex. 355
CSNet: bruce at Oregon-Grad
UUCP: ...teklabs!ogcvax!bruce
_______________________________________________________________________________
restore--etc dlw at ucbopal.CC (David L Wasley) 1 Mar 84 +FIX
There is an extremely serious bug in the 4.2bsd restore.
You may NOT be able to restore a multi-level dump, even
though the tape is readable and everything is there.
The problem is actually in ``dump''. However, the kludge
given below will allow (most) existing incremental dumps
to be read. I will post a fix to dump asap.
The problem is that the number of inodes in a filesystem
is not recorded directly in the dump tape. restore infers
the number from the size of the bit maps at the beginning
of the tape. But the bit maps are truncated to the smallest
possible size by dump before they are recorded. Thus, if
the last inode USED is 3216, the map will be (roughly)
that size, instead of the ``real'' number in the filesystem.
Unlike any previous dump/restore, this version saves the
inode and symbol table between incremental restores.
If you do a level 0 on a new filesystem, few inodes
are actually ``used''. Thus the map will be small. Several
days later you do a level 3 dump. Lots of inodes are used.
The maps are much bigger. NOW, assume you have a head crash.
The level 0 restore will have made a small map and symtable
because of what is on the level 0 tape. When you go to
put on the level 3, BINGO! restore will complain of "corrupted
directories", "expected inode M, got N", etc. This is because
the inodes it finds on the tape are outside the level 0 map, etc.
The ``real'' fix is to have dump always record the full map.
(It isn't THAT big.) Then restore would ``work''. However,
we (and you) have racks of dump tapes already. The fix
below causes restore to always use a large map. This
``works'' as long as MAXINO is larger than required for your
biggest filesystem. See the output of newfs for the number
you require (which is ipg * ncg).
REPEAT BY:
See above.
_______________________________________________________________________________
restore/restore.c--etc mckusick at ucbmonet (Kirk Mckusick) 22 Mar 84 +FIX
When using `restore i' or `restore x' on a multireel dump,
and using the recommended procedure of starting with the last
reel and working towards the first, restore will sometimes
give up after two or more reels, complaining that some list
of files are missing.
REPEAT BY:
Find a dump spanning three or more reels and request restore
to extract files that reside on all three reels, plus THE file
that starts at the end of the next to last reel and continues
onto the last reel. Then load the reels from last to first. When
the next to last reel is loaded it will proceed to its end
and begin extracting the spanning file. Restore will demand
that the last reel be loaded (so that it can finish reading
the spanning file). After restore finishes extracting the
spanning file it should request that another reel be loaded.
Instead it will report that all requested files on the earlier
reels are missing.
_______________________________________________________________________________
restore/tape.c--etc mckusick at ucbarpa (Kirk Mckusick) 7 Jan 84 +FIX
When restarting full or incremental restores using the 'R'
option to restore, the program dumps core.
REPEAT BY:
Start an incremental or full restore. (using the 'r' option)
Once it begins restoring files, send it a kill signal. Restart
the restore using the 'R' option and it will dump core.
FIX:
15c15
< static long fssize;
---
> static long fssize = MAXBSIZE;
_______________________________________________________________________________
rexec--etc jbn at FORD-WDL1.ARPA 10 Aug 84 +FIX
The "rexec" service uses TCP service port 514. Service ports
are restricted to the range 0..255; see RFC790, p. 7, and
many non-UCB systems cannot communicate with this illegal
service port. This prevents us from doing file backups with
"rdump" from a 4.2 based system (a Sun) to a system with better
tape drives that doesn't happen to run 4.2BSD.
REPEAT BY:
Examine the table used by "getservbyname".
_______________________________________________________________________________
rexecd--etc ucsfcgl!conrad (Conrad Huang) 28 Aug 84 +FIX
A bug was introduced into rexecd when it was converted to run
with the inet super-daemon. Originally, the first argument
to the routine doit() is a socket and must always be closed
before execl()ing the specified command. With the new version,
the inet daemon dup2()s the socket to standard input (descriptor
0), but rexecd still does a close() on the first argument of
doit() and so closes off standard input. The result is that
programs run with the new rexecd cannot read from standard input
(except for /bin/csh which does some really weird things).
REPEAT BY:
Create a new user "news" with password "netnews" and login
program /tmp/try2. Use the following program as try2:
#include <stdio.h>
main()
{
register int i, fd;
char buf[BUFSIZ];
fd = creat("/tmp/junk", 0644);
while ((i = read(0, buf, sizeof buf)) > 0)
(void) write(fd, buf, i);
(void) close(fd);
exit(0);
}
Then execute the following program:
#include <sys/types.h>
#include <netdb.h>
char buf[] = "Hello world\n";
main()
{
int fd;
char *host;
struct servent *rexecp;
host = "your host name";
rexecp = getservbyname("exec", "tcp");
fd = rexec(&host, (u_short) rexecp->s_port,
"news", "netnews",
"command", (int *) 0);
if (fd < 0) {
perror("rexec");
exit(1);
}
(void) write(fd, buf, sizeof buf);
(void) close(fd);
exit(0);
}
The file /tmp/junk should have the words "Hello world" in it.
FIX:
Replace
(void) close(f);
in doit() about line 177 with
if (f > 2) (void) close(f);
_______________________________________________________________________________
rlogin--ucb ucscc!ucscc!root (00050000) 16 Jan 84
A user dialed into machine (D) and then logged into a second machine
(C) with rlogin. Then C crashed. The user hung up the phone. Later
another user dialed into D and found himself in the middle of the first
user's account and session. Apparently D did not terminate the session
on loss of carrier on the dialin as it should have.
REPEAT BY:
rlogin to another machine and have it go down while you are trying
to use it. Then hang up the phone.
_______________________________________________________________________________
rlogind.c--etc watrose!srradia (sanjay Radia) 24 Nov 83 +FIX
In the routine doit() in rlogind.c at line 141 there is a
fromp->sin_port = htons((u_short)fromp->sin_port);
Shouldn't it be ntohs() instead of htons() since fromp was
received from accept() which means that it is in the the network byte
order. From what I can tell the reason for this conversion would
be to be able to do:
if ( ....... ||
fromp->sin_port >= IPPORT_RESERVED ||
.....
later on in doit().
REPEAT BY:
NOTE: this "bug" causes no problem since ntohs() and htons() both
switch two bytes.
FIX:
Change htons() to ntohs().
_______________________________________________________________________________
rogue--games brian at wisc-rsch.arpa (Brian Pinkerton) 26 Apr 84
Rogue seems to arbitrarily save games and mess up inventories.
It is not a common occurrence (it happens maybe 1 out of 20 games,
and then only after several levels).
The most common problem is that rogue just decides to save itself
in the default save file with no message to the user. The game
is then restorable, but the same thing continues to happen.
This is not a problem with the load average stuff because we don't
have it installed here at Wisconsin.
The other problem is that inventories periodically mess up. This
seems to happen right along with the save problem. Large holes
of blank lines suddenly appear in the inventory, or else about 1/2
of the pack just disappears.
REPEAT BY:
Hmmm. This seems to happen at random. If you want a save file that
exhibits the bug, I'd be glad to send it to you.
Or, if you send us the source code, we'd be more than glad to find the
problem and fix it.
thanks, brian at wisconsin.
_______________________________________________________________________________
rogue--games Support Group (agent: Tinh Tang) 17 May 84
When hit by a nymph, the reported item is missing and a few other
related items are also misiing. The missing items still appeared to count
against the pack. When wearing a ring (item 'n' on the left hand) which
did not appear in the pack and did appear when prompted for with an '='
command. When this ring is removed, it is not reported on my hand and
still not in the pack.
REPEAT BY:
the bug occurs sporadically.
_______________________________________________________________________________
rogue--games bdh at cit-750 (Brian D. Horn) 3 Jul 84
If you drop everything in your pack and try to pick something up,
the pack becomes corrupt.
REPEAT BY:
Start rogue. Drop a through e (entire pack). Move over an object to
pick it up and do an inventory (note idiocy).
_______________________________________________________________________________
rogue--games mazama!paul (Paul Fowler) <mazama!paul at Shasta> 22 Mar 84
Rogue gets very confused if you empty out your pack and then try
picking items up again. Items get duplicated, others disappear,
movement leaves little turds on the screen and sooner or later
the game hangs and/or drops you out into the shell.
Much more annoying, it gave the same behavior, or a close facsimile,
with no apparent provocation in the middle of a rather successful
game. I stepped into a room on level 9 and the game died.
When restarted from the saved file, a scroll ? had appeared
in the doorway and any movement or even inventorying dropped
me out into the shell; dropping an object gave a scrambled inventory
list and dropped me into the shell again. This behavior is
similar to that induced by emptying one's pack, but rather more annoying
since it was not deliberately induced.
REPEAT BY:
Empty your pack.
_______________________________________________________________________________
routed/startup.c--etc John Romine <jromine at uci-750a> 19 Apr 84 +FIX
Routed sets its internal flags wrong for interfaces. The flags 0x1
to 0x10 are the same as the kernel flags, but the other flag bits are
never masked out.
REPEAT BY:
Set the 'trailers', and '-arp' configuration flags for a hardware
interface with /etc/ifconfig, then start routed. routed will get
confused and delete the routing entry for that interface.
_______________________________________________________________________________
rsh.c--etc Jeff Schwab <jrs at Purdue.ARPA> 25 May 84 +FIX
The code to set up the group membership lists is mis-ordered.
If a user is in the group that rshd runs under (typically 0),
he will never recieve permissions for that group as they
are revoked by the setgid() immediately following.
REPEAT BY:
Edit /etc/group to give yourself access to the group that
rshd runs under (typically group 0). Then do an rsh
command "rsh xxx groups" where xxx is the name of the machine
and surprise! it does not show your membership in the group.
_______________________________________________________________________________
ruptime.c--ucb genji at ucbopal.CC (Genji Schmeder) 14 Nov 83
The actual working directory is misnamed in a diagnostic
message. The directory historically was /etc but RWHODIR
now defines a different place. Also, the variable "DIR *etc"
should be renamed since it is misleading. --Genji
_______________________________________________________________________________
rwhod/rwhod.c--etc jsq at ut-sally.ARPA (John Quarterman) 6 Dec 83 +FIX
Rwhod doesn't allow hostnames with dashes in them, contrary
to internet convention.
REPEAT BY:
"hostname name-with-a-dash" on a system connected to a network
with broadcast capabilities and notice rwhod (when restarted)
no longer records updates for that system.
_______________________________________________________________________________
rwhod/rwhod.c--etc salkind at nyu (Lou Salkind) 6 Mar 84 +FIX
rwhod will not send datagram packets over point to point links.
_______________________________________________________________________________
rwhod/rwhod.c--etc dpk at BRL-VGR.ARPA 4 Jul 84 +FIX
Rwhod was nlisting the kernel every 10*sleep_interval
seconds whether it needed to or not. This caused it to consume
far more CPU and disk I/O than it should have.
REPEAT BY:
Run "sa" and look at the stats for "rwhod".
_______________________________________________________________________________
sa.c--etc munnari at kre (Robert Elz) 14 Oct 83
2 problems,
1) sa -u produces rubbish output
2) commands that exit with AFORK set potentially have rubbish
added to their names (after the '*' that indicates AFORK)
REPEAT BY:
1) just run sa -u
2) run any options on sa & look at output for commands with
names like 'sh*n'.
FIX:
1) fix the printf at line 636 of sa.c 4.3 (in procedure doacct,
just after 'if (uflg) {'), it's basically rubbish. Var 'x'
is a long, being printed as %6.1f, which is main source of
trouble, but also, all the %6d's should be %6ld, and the
%.14s should be %.*s, where the arg for the * is NC (which
is 10, not 14)
2) at line 628 of sa.c 4.3, where the '*' is inserted (in doacct()
again) the line
*cp = '*';
should really be
*cp++ = '*';
if (cp < &fbuf.ac_comm[NC])
*cp = 0;
ps: sam's comments about times being in minutes instead of seconds
are irrelevant, that's what they are supposed to be (according
to the manual, and all previous versions of sa). That is one of
the few 60's in all the source code that's not related to HZ.
_______________________________________________________________________________
sa.c--etc dagobah!efo (Eben Ostby) 7 Dec 83
sa now stores times as seconds; as many (most) processes use
up considerably less than a second of user or system time,
sa's results are meaningless.
REPEAT BY:
run 2 billion cat < /dev/null > /dev/null 's
and one troff. troff will come up first on the sa sorted list,
even though the accumulated cat's should have considerably more
total time -- they don't, as each one's time was truncated to 0.
FIX:
Store accounting numbers as 60's (the way it used to be) or some
other fraction of a second. Using 60's is expensive (but would
fix the problem where sa prints everything out as 1/60'th
what it should be.) [note: another fix is to store times as
60ths in a long again, instead of two longs *burp* ]
_______________________________________________________________________________
sail--man George R. Cross <cross%lsu.csnet at csnet-relay.arpa> 11 Apr 84
No manual for the sail game is included with the distribution..
REPEAT BY:
not applicable.
FIX:
Please send me a copy of the manual.
_______________________________________________________________________________
savecore--man ihnp4!ihesa!bob (Bob Van Valzah) 21 Jun 84 +FIX
The manpage for savecore(8) should say that the number read from
the minfree file is taken with units of 1024 bytes and does not
include the 10% of the disk that is normally unavailable to users.
It'd also be nice if distributin systems came with a reasonable
minfree file set up already.
REPEAT BY:
Read the manual.
FIX:
Add information from above paragraphs to the manual page.
_______________________________________________________________________________
savecore.c--etc Jeff Mogul <mogul at Gregorio> 20 Jun 84 +FIX
Savecore takes an optional argument to specify a file besides
/vmunix as the system that was running when a crash dump
was made. This does not work properly, because savecore
uses the namelist from /vmunix even if an alternate system
is specified, and so unless the systems are almost identical
it decides that the crash dump has a bad magic number and
fails to save it.
REPEAT BY:
Configure a system differently from the one you normally run;
make sure that the address of the variable _dumpmag is different.
Call the new kernel /newvmunix; do NOT replace /vmunix
boot /newvmunix and make it crash (with a dump.)
boot /vmunix single-user, mount the appropriate filesystems,
and type
# /etc/savecore /usr/crash /newvmunix
No core dump will be saved.
_______________________________________________________________________________
script.c--ucb mazama!stew (Stewart Levin) 15 Feb 84
After configuring in the pty's to our system, I tested script(1)
on my VK100 (GIGI) graphics terminal at 9600 baud (sustained rate
is closer to 3200 baud) and got mostly garbage on my screen. Later
cat'ing the typescript file, however, produced the correct text
and plots.
I suspected the problem might be the ^S/^Q handshaking was not
being acknowledged, causing the GIGI's internal buffers to overrun
and lose characters, so I reran the test at 300 baud. (Have you
ever waited for a plot to come out at 300 baud?!!) The output
to my screen was fine.
Thus I conclude that script, or more likely the pseudo-terminal
driver, is not honoring the ^S/^Q handshaking convention.
REPEAT BY:
Running script on a terminal that handshakes.
FIX:
Actually a patch: run script at a low baud rate or try inserting
lots of delay padding into the termcap entry for the terminal
you're working on. Only the former really works for graphics
terminals which can take a very long time to process certain
graphic escape sequences which termcap (and the tty drivers)
know nothing about.
_______________________________________________________________________________
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