vance@mtxinu.UUCP (Vance Vaughan) (11/06/84)
4.2 BUGLIST ABSTRACTS from MT XINU, part 2 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...
curses/termcap--usr.lib root%oregon-grad.csnet 1 Aug 84 +FIX
Both the curses library and the termcap library have a global
variable _ospeed; hence when both libraries are used, the ld
loader gives this error message:
_ospeed: ld:/usr/lib/libcurses.a(cr_tty.o): multiply defined
It appears that the intention was that curses' ospeed is for
internal use only and should not have been global, whereas
the ospeed in the termcap package is intentionally global.
REPEAT BY:
(This problem was discovered while loading the libraries via
Franz Lisp, and I haven't come up with a simple demo of it
elsewhere. The fix below cured the problem, however.)
_______________________________________________________________________________
dbx--ucb ucbvax!decwrl!goldberg Jun 13 83
Dbx can't set the value of variables declared double.
REPEAT BY:
In
main(){double i; i = 3.0;}
if a breakpoint is set and then the command
"set i=3.0" is given, the error message "incompatible types"
is returned. "set i=3" works, but then "print i" returns
gibberish, as expected.
_______________________________________________________________________________
dbx--ucb ucbvax!decwrl!goldberg Jun 8 83
If a program has a declaration of an array which is external,
asking dbx to display an element of it fails with the the
error message "subscript out of range".
REPEAT BY:
tst.c:
#include "tst.h"
struct foo arr[10];
main () {
int i;
for (i = 0; i < 10; i++)
(*) arr[i].a = i;
}
tst.h:
struct foo {
int a,
b;
};
extern struct foo arr[];
Run dbx with a breakpoint at the line marked (*), and at the breakpoint do a
"print arr[0]".
_______________________________________________________________________________
dbx--ucb mazama!pete (Peter Mora) 13 Sep 84
dbx doesnt work for fortran,
(1) says "procedure not active" when "print"ing from a subroutine
(try printing c from junk1 below). actually, it seems to
not print any argument passed to the subroutine such as c,r and
n in the subroutine below.
(2) gives adresses rather than variable names in subroutines
(3) in the 4.1 era when it sort of worked, it printed complex
numbers incorrectly as the (imag,real) rather than (real,imag).
now, it isnt even capable of printing an array but maybe
if it can be fixed the real-imag reversal problem should
be fixed too.
(4) numerous other problems, example: dbx crashed when you
dbx "program below"
stop at 7
run
print c
Illegal instruction (ie: CRASH)
REPEAT BY:
try program below
real r(100)
complex c(100)
n=100
do 1 i=1,100
c(i)=cmplx(float(i),-float(i))
1 r(i)=i
call junk1(r,c,n)
a=2
b=3
end
subroutine junk1(r,c,n)
complex c(n)
real r(n)
a=1
b=2
d=4
e=10
do 1 i=1,n
c(i)=-c(i)
1 r(i)=e*r(i)
f=11
return
end
_______________________________________________________________________________
dbx--ucb ucbvax!decwrl!goldberg Jun 17 83
When the program below is run with a breakpoint at the line
marked with a (*), it doesn't halt at the breakpoint, although
it does print "Hello".
REPEAT BY:
main(){
int i,j,stat[10];
for (j = 0; j < i; j++)
if (stat[j] == 3)
break;
(*) if (j == i)
printf("Hello");
}
_______________________________________________________________________________
dbx--ucb jerry@ucbopal.CC (Jerry Berkman) 26 Sep 84
New version of dbx on monet says "... not active" when asked
about values of fortran subroutine arguments and common block
elements. Old version of dbx in /usr/ucb/dbx on opal prints
out the values.
REPEAT BY:
# bug in dbx - can't display args and common block elements from f77
cat << 'EOT' >! dbxbug.f
common /const/ pi
pi = 3.14159
r = 2.0
call sub(r)
end
subroutine sub(rr)
ix=0
j=rr/ix
return
end
'EOT'
f77 -g dbxbug.f
a.out
dbx << 'EOT'
list
print pi
print r
print rr
'EOT'
_______________________________________________________________________________
dbx--ucb ucbvax!decwrl!goldberg Jun 4 83
When an executable file (say a.out) is being debugged by
"dbx a.out", and the dbx job is pushed into the background
with ^Z, an attempt to execute a.out succeeds. Unfortunately
bizarre results can follow. I suspect that an attempt to
execute a.out should result in the message "Text file busy."
as happens in 4.1.
REPEAT BY:
I assume that dbx is supposed to mark executables as busy.
If not, I have examples that behave wrongly when executed
while a dbx job is stopped.
_______________________________________________________________________________
dbx--ucb ucbvax!decwrl!goldberg Jun 27 83
If a program with a large global array is run under dbx,
upon exiting dbx thrashing will occur.
REPEAT BY:
run dbx on the program
int arr[1000000];
main(){int i; i = arr[1];}
Do a 'run' followed by a 'quit'. At this point vmstat reveals
the system paging out at a very hig rate (200 pages/sec), with
system times of 70% (on an unloaded 780).
_______________________________________________________________________________
dbx/object.c--ucb sam@ucbmonet (Sam Leffler) 22 Oct 83 +FIX
The symbol table info generated by the C compiler for
enumerated types which are a member of a structure or union
causes dbx to blow up; changes are needed for both the
compiler and dbx.
REPEAT BY:
Try cc -g enum.c on the following
struct foo {
enum { RED, GREEN, BLUE } b;
};
main()
{
}
then invoke dbx, it will blow up with an "assertion failed"
message.
_______________________________________________________________________________
dbx/object.c--ucb sdcsvax!sdchema!donn 8 Jun 84 +FIX
Sometimes when debugging with dbx, mysterious functions like
'$b4' or '$b23' appear in the stack trace when the 'where'
command is given. These functions appear to share lines with
the function that appears to call them -- for example, if you
are stopped in function 'f' which appears to be called by
function '$b4' which is in turn called by function 'g', then
'f' will appear to be called from the same source file and at
the same line number in '$b4' as '$b4' is in 'g'. Moreover it
is impossible to examine local variables in 'g'.
The common feature of all functions 'g' mentioned above is
that they contain blocks or compound statements that have
their own declarations. If you stop in an inner block
with declarations, you can print out that block's local
variables (although none of the outer local variables),
which is a good indication that they are connected with
the bug.
REPEAT BY:
Clip out the following program and compile it with 'cc -g':
----------------------------------------------------------------
#include <stdio.h>
int f();
main()
{
int x;
x = 1;
if (x > 0) {
int y;
y = 3;
x = f(y);
}
printf( "%d\n", x );
exit( 0 );
}
int f( z )
int z;
{
z = z + 1;
return ( z );
}
----------------------------------------------------------------
Run dbx on the object. If you put a breakpoint anywhere in the
program, run it and check the stack when you stop, you will
find that there is a mysterious function '$b1' that is always
present. The variable 'x' in main() will not be accessible but
you can get at 'z' when 'f' is active, and you can get at 'y'
at any time (clearly a bug).
_______________________________________________________________________________
dd.c--bin hpda!hpdsd!hpdsa!eric (Eric B. Wertz) 23 Mar 84 +FIX
If file arguments given via "if=" and "of=" are the same, the
file gets trashed.
Programs like cp(1) usually catch this.
REPEAT BY:
% cat foo
This is a test file.
% dd if=foo of=foo
0+0 records in
0+0 records out (oh dear, this doesn't look good...)
% cat foo
% (sure enough...)
_______________________________________________________________________________
df.c--bin Jeff Mogul <mogul@coyote> 1 Feb 84 +FIX
This affects systems with removeable packs. If a disk
is listed in /etc/fstab, but is offline for some reason,
df dies when it tries to list the drive.
REPEAT BY:
umount a disk mentioned in /etc/fstab;
take it off line;
type "df"
_______________________________________________________________________________
dict/words--misc arnold@UCBINGRES 28 Apr 83 +FIX
at least since 4.1c came up, there are two misspellings in /usr/dict/words.
They are
conser6ative
and
conservadmsm (presumably "conservatism")
I don't know if there are others, but you might consider getting the
dictionary again, just to be sure.
Ken
_______________________________________________________________________________
diff/diffdir.c--bin gray@ucbarpa (Bob Gray) 27 Jan 84 +FIX
diff directory1 directory2
would fail to diff . files such as .login.
(Originally reported by someone at Oregon for 4.1)
REPEAT BY:
diff directory1 directory2
where both directories contain files such as .login.
_______________________________________________________________________________
diff/diffdir.c--bin John Romine <jromine@uci-750b> 23 Aug 84 +FIX
Diff doesn't list differences in files more than one subdirectory
deep when using the -r & -l options.
REPEAT BY:
Run "diff -r -l d1 d2", where directories d1 and d2 have a
subdirectory containing a file which differs. Diff won't list it.
_______________________________________________________________________________
directory--man rlee@sri-spam (Ron Lee) 20 Jul 84 +FIX
The directory operations described in DIRECTORY(3) makes use of the
header file <sys/dir.h>. Since <sys/dir.h> declares some of its
structures with defined types u_long, the header will not compile
properly without first declaring the defined types by including
<sys/types.h>. So the synopsis for DIRECTORY(3) should read in
its C code:
#include <sys/types.h>
#include <sys/dir.h>
REPEAT BY:
Compile (cc) a C program with <sys/dir.h> as an include file as
suggested by /usr/man/man3/directory.3 .
FIX:
Precede "#include <sys/types.h>" before the include file <sys/dir.h>.
_______________________________________________________________________________
dmesg.c--etc sdcsvax!sdchema!donn 29 Jan 84 +FIX
'dmesg -' is supposed to summarize the kernel messages that
have accumulated since the last time 'dmesg -' was run. If the
file '/usr/adm/msgbuf' does not exist then 'dmesg -' acts just
like 'dmesg', putting a copy of the entire message buffer on
the standard output every time it is run. No indication of
failure is returned or printed by 'dmesg -' when it fails to
find '/usr/adm/msgbuf'.
REPEAT BY:
Remove '/usr/adm/msgbuf' on an active system where 'dmesg - >>
/usr/adm/messages' is run every ten minutes by 'cron'.
'/usr/adm/messages' will grow by several megabytes a week.
_______________________________________________________________________________
dump--etc genji@UCBTOPAZ.CC (Genji Schmeder) 13 Oct 83
rmtopen return value inconsistent
_______________________________________________________________________________
dump--etc dlw@ucbopal.CC (David L Wasley) 2 Mar 84 +FIX
There is a serious bug in 4.2 bsd dump/restore. It can
prevent restore from working even though the tape is "good".
I posted a full description of this bug under
Index: /usr/src/etc/restore
even though the real bug is in ``dump''. This is because
it is necessary to fix ``restore'' in order to be able to
use existing dump tapes.
The problem is that restore needs the full inode bitmap
for the filesystem. Dump, as distributed, truncates the
map to the smallest size possible (the highest inode of
interest). This causes restore to FAIL in some cases.
REPEAT BY:
newfs /dev/rra0h ra81
dump 0 /dev/rra0h
...(add stuff to the filesystem)...
dump 3 /dev/rra0h
Now try to restore it.
_______________________________________________________________________________
dump/dump.h--etc genji@UCBTOPAZ.CC (Genji Schmeder) 9 Oct 83 +FIX
Return codes from dump and rdump are defined
X_FINOK 1
X_REWRITE 2
X_ABORT 3
It is obvious that X_FINOK means success and the
others indicate different degrees of failure.
However, the functions dealing with remote tapes,
(in dumprmt.c) return 0 for success and 1 for failure.
This inconsistency is not simply resolved by
merely changing dumprmt.c function returns, since those
functions are also used by /etc/rrestore command.
I suggest you redefine dump return codes like this
X_FINOK 0
X_ABORT 1
X_REWRITE 2
Then no change will be needed in dumprmt.c or rrestore.
Also, you should mention the return code values in
dump manual page. --Genji
_______________________________________________________________________________
dump/dumpitime.c--etc sdcsvax!sdchema!donn 27 Mar 84 +FIX
When you run dump, it typically prints out an estimate of the
number of tapes it needs and the expected number of 1K blocks
of data on those tapes. If a file on the filesystem being
dumped has holes in it, the estimate can be way off. (A hole
is a place in a file where no blocks have been allocated,
typically found in database files. See lseek(2) if you're
mystified.)
REPEAT BY:
Make a file with holes in it and try to dump the file system.
In our case dump came back with:
DUMP: estimated 1794142 tape blocks on 50.53 tape(s).
It should have said:
DUMP: estimated 132608 tape blocks on 3.74 tape(s).
This is unnerving to say the least.
_______________________________________________________________________________
dump/dumpitime.c--etc sun!shannon (Bill Shannon) 12 Sep 83 +FIX
When you do a full dump of a file system the "Date of last
level x dump" message has nothing substituted for the x.
REPEAT BY:
dump 0f /dev/null /dev/rhp0a
_______________________________________________________________________________
dump/dumpmain.c--etc root%oregon-grad.csnet@csnet-relay.arpa 27 Mar 84 +FIX
"dump" reports incorrect estimates of tape use when
given the "c" (cartridge) key. This will probably
have more serious consequences if multiple-cartridge
dumps are attempted.
REPEAT BY:
Dump root to /dev/null:
% dump 0cf /dev/null /
Again, using correct length of 1700' (1800' minus slop)
for a DC300XL tape cartridge (450', four tracks):
% dump 0csf 1700 /dev/null /
Estimate of tape usage will be different (correct) in second
example, which explicitly specifies length.
_______________________________________________________________________________
dump/dumpmain.c--etc genji@ucbopal.CC (Genji Schmeder) 26 Jul 84 +FIX
/etc/dump does not object to writing output file
onto the very filesystem being dumped.
This procedure cannot be completed and the filesystem
may be filled.
_______________________________________________________________________________
dump/dumpmain.c--etc root.Oregon-Grad@Rand-Relay 17 Aug 83 +FIX
"dump" and "rdump" report incorrect estimated tape number
estimates for 9-track tapes.
REPEAT BY:
Execute any dump command, without the "c" key (i.e., for 9-track),
and preferably one that will dump slightly under 1 tape full.
The printout of estimated blocks is correct, but number of tapes
is high by about 50%, e.g.:
Before fix:
DUMP: estimated 34721 tape blocks on 1.42 tape(s).
After fix:
DUMP: estimated 34721 tape blocks on 0.89 tape(s).
_______________________________________________________________________________
dump/dumpoptr.c--etc allegra!rdg Jul 2 83 +FIX
the dump program searches the file /etc/fstab to translate
file system names into device names. when one file system
name happens to be the same as a prefix of another file
system name, dump may select the wrong device!
the dump program then dumps the wrong file system.
REPEAT BY:
create one file system called "l1" and a second file system
named "l1backup". make the appropriate entries in fstab
with the "l1" entry occuring after the "l1backup" entry.
now issue the command:
dump 0u l1
the device on which l1backup is mounted will be dumped.
FIX:
the file dumpoptr.c contains the proceedure which searches
the fstab entries for the desired named file system.
during the search, it uses strncmp to look for a match
checking no more than strlen(filesystemname) characters.
thus, it never bothers to match the NULL at the end of the
filesystemname string with the NULL which must also be present
in the name contained in the fstab entry.
to correct the problem, one more character must be checked.
the statement
keylength = min(strlen(key), sizeof (dt->fs_file));
should be changed to
keylength = min(strlen(key)+1, sizeof (dt->fs_file));
_______________________________________________________________________________
dump/dumptape.c--etc Dave Johnson <ddj%Brown@UDel-Relay> 11 Oct 83 +FIX
dump stops writing on a tape volume long before the real end
of tape, and uses more volumes than it estimated. The estimated
amount is fairly accurate, but the tape length used is not accounted
for the same way. In particular, the inter-record gap is estimated
at 0.3" for 6250, but the value used is hardwired at 0.7" in dumptape.c
and dumprtape.c (which is the 800 and 1600 bpi value).
REPEAT BY:
Dump a filesystem of larger than 145 megabytes, using the non-rewind
tape drive at 6250 bpi. When it asks to change tapes, look how close
it got to the end of the tape (almost 500 feet left when I tried it).
_______________________________________________________________________________
dump/dumptraverse.c--etc srradia@watmath.UUCP (sanjay Radia) 5 Oct 84 +FIX
A serious bug exists in dump.
Dump makes a pass through all the inodes and marks the inodes to be
dumped in dirmap & nodmap. However, if the system is busy the inodes
can be deleted and possibly reallocated for other files.
In the next pass, when dumping inodes, dump does not bother to check to see if
the inodes are still allocated and in the case of directories does not check to
see the inode is still a directory.
Now, the dump tape has a bunch of directories (directory-zone) followed
by non-directories and as soon as restore sees a non-directory it thinks it has
scanned the directory-zone. Thus if a directory inode is delelted (and maybe
realloced to a file) between the 1st & 2nd passes of dump, the dump tape
will not be correctly read by restore (you will loose some (a lot) of the
directory information).
REPEAT BY:
Create about 3 directories and start a dump on the file system.
When dump asks you to mount the tape delete one of the three
directories (the one with the lowest inode #). Now continue with the
dump.
Do a "/etc/restore ivd". You will see that restore will not
know of any directories with inodes greater than the the one you deleted
(ie they will be marked as regular files and not as directories). You
can check this out by doing a "lc" in restore's interactive mode.
_______________________________________________________________________________
ed--man Jay Lepreau <lepreau@utah-cs> 5 Apr 84 +FIX
It says the 'n' command is there but it's not. This was
apparently added in sys III or later. I expect there
are other missing commands too which are doc'ed.
REPEAT BY:
man ed
ed /etc/group
1n
FIX:
Either fix man page, or get new ed (when 4.x requires a USG
license perhaps).
_______________________________________________________________________________
efl--usr.bin Vincent Broman <broman%BUGS@Nosc> 16 Feb 84 +FIX
efl(1) crashes in flames (i.e. in infinite recursion) when run even
on trivial programs. One of the causes is that the author included a
"very stupid" memory allocator in his program, called at various levels as
intalloc(), alloc(), calloc(), malloc(), cfree(), and free().
It is not able to handle allocations of more than 256 longwords at a chunk.
Unfortunately, he uses stdio, which trustingly calls malloc() and free()
with 4096 byte arguments in _filbuf() and fclose(). Worse, his fatal error
handler also calls exit() --> _cleanup() --> fclose().
REPEAT BY:
echo '' > a.e
efl a.e
FIX:
Use setbuf(3S) after each fopen(). May not solve everything.
Please run programs once before distributing them.
_______________________________________________________________________________
error--ucb mazama!stew (Stewart Levin) 19 Jan 84
Under some circumstances error ignores the suffix touch list
specified by the -t flag and improperly brings include files
up under vi.
REPEAT BY:
Running the command checkout test.c with the files
| |
| checkout: |
| |
| #! /bin/csh |
| lint -lc $* -n |& error -v -t ".c" |
| |
| test.c: |
| |
| #include "test.main" |
| MAIN() |
| { |
| return((int) pi); |
| } |
| |
| test.main: |
| |
| #include "test.h" |
| main() |
| { |
| MAIN(); |
| } |
| |
| test.h: |
| |
| #include <stdio.h> |
| #include <math.h> |
| #ifndef pi |
| static double snftEkd=3.1415926535897932384626434; |
| #define pi snftEkd |
| #endif |
| |
FIX:
Reinstall 4.1bsd error, removing the signal call in onintr()
_______________________________________________________________________________
error/errorinput.c--ucb jerry@ucbopal.CC (Jerry Berkman) 17 Sep 84 +FIX
Get extra output from error which confuses users. For script
under 'Repeat-By:', the initial output is:
2 non specific errors follow
[unknown] Error. No assembly.
[unknown] Error. No assembly.
2 files contain errors "file1.f" (2), "file2.f" (1)
File "file1.f" has 2 errors.
2 of these errors can be inserted into the file.
File "file2.f" has 1 error.
1 of these errors can be inserted into the file.
You touched file(s): "file1.f", "file2.f"
After the fix:
2 files contain errors "file1.f" (2), "file2.f" (1)
File "file1.f" has 2 errors.
2 of these errors can be inserted into the file.
File "file2.f" has 1 error.
1 of these errors can be inserted into the file.
You touched file(s): "file1.f", "file2.f"
REPEAT BY:
#
cat << 'EOT' >! file1.f
integer foobar(30)
foobar(2) = a^b
cal wow
end
'EOT'
cat << 'EOT' >! file2.f
print *, ' hi '
badd
end
'EOT'
f77 file1.f file2.f |& error
_______________________________________________________________________________
error/errormain.c--ucb felix!zemon (Art Zemon) 25 May 84 +FIX
Error(1) will not work if it is run when not attached to a
terminal. For example, error(1) will fail when run under
control of at(1) or the MDQS batch(1) command.
The reason is that error(1) always attempts to open
/dev/tty. Error(1) exits if the open fails. It is only
necessary to open /dev/tty if the -q option is given.
This applies to error(1) as distributed with 4.2bsd. It
probably also applies to earlier versions. The sccsid line
from out version of error(1) is:
*sccsid = "@(#)errormain.c 1.4 (Berkeley) 5/4/82";
REPEAT BY:
Execute something like this within an MDQS batch queue using
the C shell:
( cc ... |& error > error-stdout ) >& error-stderr
"error-stdout" should contain standard status information
from error(1) and "error-stderr" should be empty. Instead,
"error-stdout" will be empty and "error-stderr" will contain
the message "error: Can't open /dev/tty to query the user.".
_______________________________________________________________________________
error/errortouch.c--ucb jerry@ucbopal.CC (Jerry Berkman) 17 Sep 84
According to the manual:
-n Do not touch any files; all error messages are sent to
the standard output.
-t ... Files whose suffixes do not appear in the suffix
list are not touched ...
However, these have no effect at all unless -q is also specified.
I.e. error -n still touches files. The -n and -t options only
effect oktotouch() in errortouch.c; it is only called by preview().
It is clear preview() can only return false unless -q is specified;
so the effect of -n and -t are lost unless -q is specified.
Here is the output for the 'Repeat-By:' script:
1 non specific errors follow
[unknown] Error. No assembly.
1 file contains errors "bla.f" (1)
File "bla.f" has 1 error.
1 of these errors can be inserted into the file.
You touched file(s): "bla.f"
Either fix the code or fix the man page.
REPEAT BY:
#
cat << 'EOT' >! bla.f
fooey
'EOT'
f77 bla.f |& error -n
_______________________________________________________________________________
ex--ucb ucsfcgl!blia!eric (Eric Allman) 16 Feb 84
If the "version" command is in a .exrc file, the version number
is printed out twice. This does not occur if the :version
command is issued from inside vi.
REPEAT BY:
Add the line "version" to your .exrc file.
Enter vi. The version number will be printed out twice.
(You probably have to unsetenv EXINIT for this to work.)
_______________________________________________________________________________
ex--ucb hamachi@ucbkim (Gordon Hamachi) 19 Dec 83
When I use the ":f" command to change the name of the file I'm editing,
vi gets confused about the r/w status of the new file. It remembers
the status of the old file (which may be read-only) even though the
status of the new file may be different.
REPEAT BY:
I run vi on a file that is read-only r--r--r--, "% vi protected".
While in vi I change the name of the file, ":f writeable" and then
write the file, ":w writeable". Then I try to write it again,
":w writeable". I get an error message saying "File is read-only",
even though the mode of writeable is rw-r--r--. Note, this is NOT
a problem that ":w! writeable" solves.
_______________________________________________________________________________
ex--ucb raphael@wisc-crys.arpa (Raphael Finkel) 22 Mar 84
If a cycle of symbolic links exists, when vi is asked to open one of the
files in the cycle, it gets a system error 62, which it should report as
too many levels of symbolic links. (Cat, for example, reports the error
correctly.) Instead, it reports "system error 62".
REPEAT BY:
ln -s tmp tmp1
ln -s tmp1 tmp
vi tmp
_______________________________________________________________________________
ex--ucb leres (Craig Leres) 8 Dec 83
Vi version 3.7 has trouble when the interrupt character is
typed too soon after the escape character.
REPEAT BY:
Enter vi and (rapidly) type the sequence <escape><interrupt>,
hit ^L to fix the screen foobar that results, and then observe
that a line containing the word "Interrupt" has replaced the
current line.
_______________________________________________________________________________
ex--ucb ttang@Uci Nov 1 83
There was a problem with vi. If a user were in the middle of his
file while doing the editing and gave a command such as "nn^B"; i.e.
a string of digits nn and a control-B(he wanted to go nn pages
backward). Vi just logged him off the system and gave a segmentation
fault(core dumped) message. This shouldn't happen this way and vi
should ignore this command.
REPEAT BY:
Edit an existing file with vi, move to the next couple of pages,
then enter say "99^B". Vi will emit the message: Segmentation fault
(core dumped) and log you off. I believe that will happen for any
such command as: "nnn^x" where control-x is any valid command.
Operating system: 4.1absd.
/ttang
_______________________________________________________________________________
ex--ucb khalsa@ucbear (=Guruprem Singh Khalsa) 26 Jul 84
Vi (ex in visual mode) does not reinitialize the screen
correctly when a stopped editing session is brought back into
the foreground, IF the cursor happens to have been on the
'wrapped-around' portion of a line which exceeds the width of
the screen when the job was stopped. Vi leaves the screen
completely blank, and just puts the cursor in the right place!
REPEAT BY:
Edit any file. Generate a long line, which must be 'wrapped' onto
more than one line on the screen.
Normal: Put the cursor on any character of the early part of the line.
Stop the job with control-Z. Bring the job back into the foreground
with 'fg'. Note that everything is as it should be.
Bug: Put the cursor on any portion of the 'wrapped' part of the
long line. Stop the job with control-Z. Bring the job back into the
foreground with 'fg'. Note that the screen is blank, and that the
cursor is out in the middle of nowhere. Press the escape key. Note
that the screen is now properly refreshed, and that the cursor is
where it should be.
It turns out that pressing any key gets things to show up on
the screen again, so it's not a serious problem, but naive
users will be non-plussed by this behavior, should they happen
to stumble into it.
FIX:
Have the program note when the cursor is on a 'wrapped' portion of
a long line, and have it refresh the screen when it discovers
it is being revived after being stopped in that state. The code
should catch SIGCONT.
Thank you.
Guruprem Singh Khalsa
Principal Programmer
Electrical Engineering and Computer Sciences
Computer Systems Support Group
181M Cory Hall
2-6744
_______________________________________________________________________________
ex/ex_vadj.c--ucb ihnp4!cmcl2!rna!dan 13 Apr 84 +FIX
On ANSI/VT-100 like terminals which have termcap's CS, RC, SC
defined, VI ignores AL and DL (insert line and delete line) (which in
itself is probably not good) and emulates the AL and DL functions by
changing the scrolling region and scrolling in or out a line.
The code which emulates DL with CS had LI-1 coded as 23, which
assumes a 24line VT100. 23line VT100's (i.e. VT100's with "status-line")
and other terminals like the CIT-500 which has 64 lines failed to
emulate correctly.
REPEAT BY:
Set termcap entry of a VT100 to something other than 24 lines
(e.g. 23 lines) and enter VI and delete a line.
_______________________________________________________________________________
ex/ex_vops2.c--ucb sdcsvax!sdccsu3!madden@Nosc (Jim Madden) 2 Nov 83 +FIX
When asked to do a put of a partial line which causes a
wrapmargin overflow, vi will frequently mangle the new
text or other nearby parts of the file because of mis-guided
attempts to optimize the screen display. Further, if
abbreviations defined by "abbr" commands appear in the new
text, they will be expanded during the put. (This might
be regarded as feature.)
REPEAT BY:
The following short list of vi commands will cause the
problem if executed on an 80 column terminal:
vi NEWTESTFILE
:set wrapmargin 8
aa b c d e f g h\E^y$$pppp
At the fourth p command, the inserted text will not be the
expected "a b c d e f g h" but will be truncated to "a b c d
e". Successive p commands will cause other unexpected
results.
_______________________________________________________________________________
explain--bin eggert@ucsbcsl.UUCP 13 Jan 83 +FIX
The command `explain' crashes when the current directory is not
writable, because it creates its temporary file in the current
directory. It doesn't need to create a temporary file at all.
Here is the old (4.1bsd) version of explain:
trap 'rm $$; exit' 1 2 3 15
D=/usr/lib/explain.d
while echo "phrase?";read x
do
cat >$$ <<dn
/$x.* /s/\(.*\) \(.*\)/use "\2" for "\1"/p
dn
case $x in
[a-z]*)
sed -n -f $$ $D; rm $$;;
*) rm $$;;
esac
done
FIX:
Here is a fixed version:
D=/usr/lib/explain.d
while echo 'phrase?'
read x
do
case $x in
[a-z]*) sed -n /"$x"'.* /s/\(.*\) \(.*\)/use "\2" for "\1"/p' $D
esac
done
_______________________________________________________________________________
expr(1)--bin ariel!vax135!floyd!clyde!watmath!utzoo!bin May 14 84 +FIX
In the function ematch(), expbuf is declared with the #define'd
constant ESIZE (= 256). But, the function compile is called as
follows:
compile(p, expbuf, &expbuf[512], 0);
The wired-in 512 should be changed to ESIZE.
This bug is present in at least V7, System 3, and 4.1BSD.
--
David Trueman @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!david
REPEAT BY:
Inspection.
FIX:
231c231
< compile(p, expbuf, &expbuf[512], 0);
---
> compile(p, expbuf, &expbuf[ESIZE], 0);
_______________________________________________________________________________
f77--usr.bin sdcsvax!sdchema!donn 31 May 84 +FIX
Another f77 bug... Sometimes a comparison of two CHARACTER*1
values gets the wrong result. Specifically this occurs when
one operand of the comparison is a CHARACTER*1 expression (a
function call or a type conversion) and the other operand is
any CHARACTER*1 value. This is another bug contributed by
Jerry Berkman at UC Berkeley; he apparently got it from a
friend. This bug is so specific that it's sheer luck that
anyone ever managed to exercise it.
REPEAT BY:
Clip out the following program (courtesy of Jerry Berkman)
and compile it.
----------------------------------------------------------------
character*1 getchr,ich
ich=getchr("A")
if(ich.ne.getchr("A")) write(6,100)
100 format("Error in character functions")
stop
end
character*1 function getchr(ich)
character*1 ich
print 8000, ich, ichar(ich)
8000 format('in getchr with ich = ',a1,' (',16r,i6.2,')')
getchr=ich
return
end
----------------------------------------------------------------
When run it prints 'Error in character functions' (surprise!).
A little poking around reveals the following gaffe in the
assembly language code:
----------------------------------------------------------------
pushl $1 # 'ich=getchr("A")'
pushal {0101,00}
pushl $1
pushal -1(fp)
calls $4,_getchr_
movb -1(fp),{ich}(r11)
pushl $1 # 'if(ich.ne.getchr("A")) ...'
pushal {0101,00}
pushl $1
pushal -1(fp)
calls $4,_getchr_
cvtbl -1(fp),r1
cmpl r0,r1 # Oops! What's in r0? Not 'ich'!
jeql L15
----------------------------------------------------------------
_______________________________________________________________________________
f77--usr.lib dlw@ucbopal.CC (David L Wasley) 7 Jun 84 +FIX
The runtime I/O system will hang with some illegal format specs.
It should either "work" or abort. The symptom here is that the
program appears to never return from the READ statement.
Repeat By:
Try the following:
program badio
character*20 fmt
fmt = "(0f0.0)"
read (*, fmt) x
end
_______________________________________________________________________________
f77--usr.bin m128a4@ucbbrahms (Matthew P. Wiener) 4 Oct 84
assigns apparently do not work with statement numbers that
appear later than the assign statement itself.
REPEAT BY:
Create a file called dumb.F containing:
program dumb
integer line,i
#ifndef BUG
100 format(i5)
#endif
i=123
assign 100 to line
print line,i
stop
#ifdef BUG
100 format(i5)
#endif
end
Compiled as 'f77 dumb.F', it works, with output ' 123'.
Compiled as 'f77 -DBUG dumb.F', it doesn't, and I get:
* write sfe: [100] error in format
* logical unit 6, named 'stdout'
* lately: writing sequential formatted external IO
* part of last format: ^D
_______________________________________________________________________________
f77--usr.bin sdcsvax!sdchema!donn 27 Mar 84 +FIX
F77 considers two variables from the same COMMON block to be
the same variable for the purposes of common subexpression
elimination. This is almost always wrong.
REPEAT BY:
Copy the following program into a file com.f. Compile it with
the optimizer turned on.
----------------------------------------------------------------
program com
common /x/ a, b, c, d
integer result, a, b, c, d
a = 2
b = 3
c = 4
d = 5
result = a * b + c * d
print *, result
stop
end
----------------------------------------------------------------
The expected result of running the program is '26'. What the
program actually prints is '12'. To see why, here is the code
produced (comments and other prettification added):
----------------------------------------------------------------
.globl _MAIN_
.set LF1,4
_MAIN_:
.word LWM1
subl2 $LF1,sp
jmp L12
L13:
movl $2,_x_
movl $3,_x_+4
movl $4,_x_+8
movl $5,_x_+12
mull3 _x_+4,_x_,-4(fp)
addl3 -4(fp),-4(fp),{result} # Mistake!
pushal v.3
calls $1,_s_wsle
pushl $4
pushab {result}
pushal {1}
pushal {3}
calls $4,_do_lio
calls $0,_e_wsle
pushl $0
pushal {00,00}
calls $2,_s_stop
ret
.align 1
_com_:
.word LWM1
L12:
moval v.1,r11
jmp L13
----------------------------------------------------------------
The two multiplies were treated as common subexpressions, and
the same temporary [-4(fp)] was used to store both results.
_______________________________________________________________________________
f77--usr.bin sdcsvax!sdchema!donn 2 Apr 84 +FIX
An f77 program that uses certain constant integer exponents
greater than 4 will not get the proper results if the optimizer
is turned on. In general the values produced are much larger
than they should be.
REPEAT BY:
Compile the following program with the optimizer turned on
and run it:
----------------------------------------------------------------
program powbug
integer i
i = 10
i = i ** 5
print *, i
stop
end
----------------------------------------------------------------
If your f77 is broken it will print '1000000' instead of
'100000'.
_______________________________________________________________________________
f77--usr.bin dlw@ucbopal.CC (David L Wasley) 6 Jun 84 +FIX
Under some circumstances entry points required by routines
in libU77.a are not found because they exist in earlier libs.
REPEAT BY:
I don't have a specific case in front of me, but it has been
reported to me by several users.
_______________________________________________________________________________
f77--usr.bin astrovax!draine (Bruce Draine) 25 Feb 84
Incorrect evaluation of complex arithmetic expressions
involving library functions CCOS and CSIN. For example,
the fortran expression
A=CCOS(Y)/CSIN(Y)
with A and Y having been previously "typed" by a
COMPLEX A,Y
statement, is not being evaluated correctly for arbitrary
values of the complex variable Y.
It is not known to what extent this problem may also be
endemic to other constructions [e.g., A=CSIN(Y)/CCOS(Y) ].
REPEAT BY:
Compiling and running the following simple program:
C PROGRAM TO TEST APPARENT BUG IN F77 COMPILER
C B.T.DRAINE,PRINCETON UNIV. OBS., 84/2/19
COMPLEX Y,A,B,C
Y=(4.601765,-3.839218)
WRITE(6,9900)Y
9900 FORMAT(' Y=',1P2E14.7)
C INDIRECT EVALUATION OF COTANGENT(Y)
A=CCOS(Y)
B=CSIN(Y)
C=A/B
WRITE(6,9969)A,B
9969 FORMAT(' A=CCOS(Y)=',1P2E14.7,' B=CSIN(Y)=',2E14.7)
WRITE(6,9970)C
9970 FORMAT(' C=A/B=',1P2E14.7)
C DIRECT EVALUATION
C=CCOS(Y)/CSIN(Y)
WRITE(6,9971)C
9971 FORMAT(' C=CCOS(Y)/CSIN(Y)=',1P2E14.7)
STOP
END
The following output is generated by this program running under
4.2 BSD on our Vax-11/750 with FPA:
***** testf77 compiled with no options 84/2/19 *****
output follows:
Y= 4.6017652e+00-3.8392179e+00
A=CCOS(Y)=-2.5673470e+00-2.3091778e+01 B=CSIN(Y)=-2.3113155e+01 2.5649724e+00
C=A/B= 2.0288443e-04 9.9909759e-01
C=CCOS(Y)/CSIN(Y)= 1.0000000e+00-1.4885653e-09
***** testf77 compiled with -C option 84/2/19 *****
output follows:
Y= 4.6017652e+00-3.8392179e+00
A=CCOS(Y)=-2.5673470e+00-2.3091778e+01 B=CSIN(Y)=-2.3113155e+01 2.5649724e+00
C=A/B= 2.0288443e-04 9.9909759e-01
C=CCOS(Y)/CSIN(Y)= 1.0000000e+00-1.4885653e-09
FIX:
Unknown to me.
_______________________________________________________________________________
f77--usr.bin sdcsvax!sdchema!donn 28 May 84 +FIX
When an f77 program is compiled with the optimizer enabled,
side effects of an expression are evaluated twice if that
expression is squared. This was originally pointed out to
me by Jerry Berkman at UC Berkeley.
REPEAT BY:
Put the following f77 subroutine in a file fsq.f and compile
it to assembly language with the optimizer turned on:
----------------------------------------------------------------
subroutine fsq( x )
real f, x
x = f( x ) ** 2
return
end
----------------------------------------------------------------
If the bug is present in your compiler you should see the
following (although probably not so pretty):
----------------------------------------------------------------
.globl _fsq_
.set LF1,4
_fsq_:
.word LWM1
subl2 $LF1,sp
jmp L12
L15:
pushl 4(ap)
calls $1,_f_
movl r0,-4(fp)
pushl 4(ap)
calls $1,_f_
mulf2 -4(fp),r0
movl r0,*4(ap)
ret
.align 1
L12:
jmp L15
----------------------------------------------------------------
_______________________________________________________________________________
f77--usr.bin allegra!astrovax!gam (Gary Mamon) 19 Mar 84
4.2 F77 mishandles the following in single precision:
z = x1**alpha + x2**alpha + ... + xlast**alpha
where alpha is a floating point constant, and z and x sub i
are real variables.
F77 returns for z the value N*xlast**alpha, where N is the
number of terms in the sum.
Furthermore F77 mishandles the following in both single and
double precision.
z = (x1-y1)**alpha + (x2-y2)**alpha
where again alpha is a floating point constant, and z, the
x sub i and the y sub i are real (real*8 in double precision)
variables.
REPEAT BY:
compiling and running the following source with f77.
x = 6.
y = 8.
x2 = 1.
y2 = 1.
z = x**2.+y**2.
z2 = (x2-x)**2.+(y2-y)**2.
print *,z,z2
stop
end
The program will print "128 98" instead of "100 74"
The same program starting with the line
implicit real*8 (a-h,o-z)
will print "100 98" instead of "100 74"
FIX:
Unknown.
Comment:
This is one of several 4.2 BSD F77 bugs already discovered at
our site. The majority of Fortran users here are now using the
4.1BSD F77 compiler.
_______________________________________________________________________________
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.