vance@mtxinu.UUCP (Vance Vaughan) (11/09/84)
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@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@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@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@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@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@Oregon-Grad UUCP: ...teklabs!ogcvax!bruce _______________________________________________________________________________ pascal/utilities/pc.c--ucb raphael@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@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@BERKELEY _______________________________________________________________________________ pc--usr.lib mls@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@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@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@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@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@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@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@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@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@host1 (not me) be in the .rhosts of name2@host2. REPEAT BY: Try doing one. _______________________________________________________________________________ rcp.c--ucb mlgray@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@ucbcory. _______________________________________________________________________________ rcs/{ci.c,rcsgen.c}--new lepreau@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@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@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@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@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@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@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@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@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@Oregon-Grad UUCP: ...teklabs!ogcvax!bruce _______________________________________________________________________________ restore--etc dlw@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@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@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@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@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@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@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@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@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@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@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@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@nyu (Lou Salkind) 6 Mar 84 +FIX rwhod will not send datagram packets over point to point links. _______________________________________________________________________________ rwhod/rwhod.c--etc dpk@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@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@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@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@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.