BSD 4 development

[unix-history] / usr / news / v7bugs

From bill Thu Oct 18 01:41:53 1979
To: v7bugs
Subj: bug in icheck
Cc:  sklower

there is a bug in the icheck program due to the declaration of
	unsigned short s_fsize
in <filsys.h>... in the places where XXX.s_fsize is used in comparisons
in icheck.c, it should be cast to an integer.  comparisons of the form
	if (YYY < XXX.s_fsize)
are deadly, since YYY may be negative.  since XXX.s_fsize is positive,
but signed, YYY is treated as unsigned, and havoc results from the fact
that the comparsion fails.   if an inode has a (bad) negative block
number in it (YYY < 0) then icheck will (hopefully) core dump or screw
up in some other way.
	bill

From bill Thu Oct 18 01:48:39 1979
To: v7bugs

the first set of fixes i sent around for the tty driver showed up further
problems (e.g., now the tty driver hangs waiting for input on going into
vi sometimes)... you should steal /usr/staff/ozalp/sys/sys/tty.c if you
put in this first change and diff and take some more fixes.  dmr thinks
there may still be a problem with 0377's in raw input; if you are worried
about this, change tty.c so that it always flushes if coming from/going
to raw, i.e. no TIOCSETN for these transitions... no problem if you
do this, i think

From root Thu Oct 18 02:05:58 1979
To: v7bugs

s/s_fsize/s_isize/ in previous mail... sorry.

From uucp Wed Sep 26 13:16:38 1979
>From tom Tue Sep 25 22:01:30 1979 remote from ucsfcgl
To: Bob Kridle, Ed Gould, Bill Joy
Re: Bug in version 7 optimizer of dmr's pdp-11 compiler

A bug involving unsigned integers has surfaced in the version 7 C compiler.
After installing the following fix you should recompile:
	mkfs.c
	dcheck.c
	passwd.c
	getty.c
	mail.c
	pstat.c

>From uucp Mon Jul 23 22:53:59 1979
>From dmr Mon Jul 23 23:59:07 1979 remote from research
Here is the change needed to fix the optimizer.
The file is /usr/src/cmd/c/c21.c.
This is in routine rmove, after case CBR, the first two
lines in the 'if r==0' clause:

190,191c
< 				p->back->back->forw = p->forw;
< 				p->forw->back = p->back->back;
---
> 				if (p->forw->op==CBR
> 				  || p->forw->op==SXT
> 				  || p->forw->op==CFCC) {
> 					p->back->forw = p->forw;
> 					p->forw->back = p->back;
> 				} else {
> 					p->back->back->forw = p->forw;
> 					p->forw->back = p->back->back;
> 				}

The old code deleted a test or compare with constant operands
and a following conditional branch that would always fail.
The new code only deletes the branch (leaves the test)
if the combination is followed by another instruction that
needs the condition codes.  The test and second branch are liable
to be deleted later.


From michael Mon Oct 29 20:26:58 1979
To: v7bugs
Subj: Tm.c

There is a bug in the released version of V7 UNIX.  The RLE bit (record
length error) is defined wrong.  You should
/RLE/s/0100$/01000/
asap
The effect is that the bit which is selected is the select remote bit
which is on when the drive is on line and all errors are effectively
ignored (programs get a short write) and no retries are attempted.
We have also upped the retry count (from 2) since our tape is behind two 
disk controers and doesn't always get the bus in  time.

From michael Wed Oct 31 19:44:55 1979
To: v7bugs
Subj: pcc

we have a pile of fixes and/or bugs for the pdp-11 version of pcc
if anyone is interested.

From bill Mon Dec 31 14:37:09 1979
To: v7bugs
Subject: bug in exece()
Cc:  tbl jfr mhtsa!ted

there is a nasty bug in exece() (which appeared in 50 changes)
after the
	bp = bread(swapdev, (daddr_t)(dbtofsb(swplo+bno)+(nc>>BSHIFT)));
put
	bp->b_flags &= ~B_DELWRI;
else the buffer may stay in the cache with DELWRI set and clobber a
random block in the swap area at some later time.

From dmr Thu Jan 17 00:09:30 1980
Forward to v7 bugs manager:
The stand-alone boot loader for PDP-11 systems turns on
22-bit addressing mode on 11/70's but does not set up the unibus
map.  Thus trying to boot on 11/70's with Unibus RP03's is a loss.
Try booting V6 and don't turn the machine off.
Failing that, set-em-up 1-1 by hand.

From mark Fri Feb 15 21:43:11 1980
To: v7bugs
Subject: bugs in learn, tty driver
Cc: gst
"learn eqn" does a really horrible job of handling terminals that aren't dtc's.
For starters, it seems to look for term (not TERM) in the environment, and then
not do anything with it.  But it does bomb out gracefully if term isn't set,
or not gracefully if term is set to something nroff doesn't know about.
It also behaves rather strangely if you set term=lpr and admit it didn't
come out right.
(Fix: change the learn shell script to use TERM instead of term.  Change
nroff so if the -T terminal doesn't exist it uses lpr.  Fixed learn shell
script available to anyone who's interested.)

Learn editor has scripts that assume there is no "w" program.  Since there
does exist such a program (nonstandard except in VM/Unix) this example
should be changed to use q.

It does seem to be possible to learn eqn on a regular crt terminal by using
	neqn file | nroff -ms | colcrt -2
although this doesn't do anything about Greek letters.


When you change your interrupt character from DEL to something else,
the BREAK key still maps to DEL instead of interrupt.  This is in
dz.c et.al., and can be found by searching for DEL or 0177.
The fix is to replace the 0177 by something like tun.c_intr;


From root Wed Apr 16 20:04:20 1980
To: v7bugs
Subject: bug in /bin/time
it prints null characters.
what is needed is
	if (c)
before each (of 2)
	fprintf(stderr,"%c",c);
's
	bill

From mark Sat Apr 19 01:18:51 1980
To: v7bugs
Subject: bug in pdp-11 C optimizer
The following program demonstrates a bug in the V7 pdp-11 /lib/c2.
#include <stdio.h>
main () {
	int x;
	int t1;

	x = 0;
	x += 1;
	t1 = x != 1;
	printf("x=%d, t1=%d\n", x, t1);
	exit(0);
}
It should print 1, 0, but it prints 1, 1.  Seems that the optimizer has
correctly noticed that the value of x can be predicted at compile time
and hence the comparison can be precomputed, but it does the precomputation
wrong.  Changing the 2 assignments to x to "x = 1" works properly.

I don't know what the status of c2 is, I seem to recall someone telling me
many years ago that c2 made certain mistakes and that some programs just
couldn't be optimized.  If this is the case you probably don't care about
this, but if c2 is supposed to handle everything right, have fun.
	Mark

From bill Thu May 15 16:27:26 1980
To: v7bugs

the fileno macro omits parenthesization, i.e. it reads
	#define fileno(p)	p->_file
it should be defined as
	#define	fileno(p)	(p)->_file

From mark Wed May 21 13:11:49 1980
To: v7bugs
Subject: stdio fileno bug

	From uucp  Wed May 21 04:17:22 1980
	>From daemon Tue May 20 23:36:57 1980 remote from vax135
	>From uucp Tue May 20 21:23:42 1980 remote from duke
	>From smb Tue May 20 21:17:24 1980 remote from unc
	Your redefinition of fileno to fix the bug is wrong; it should be
	
		#define fileno(p)	((p)->file)
	
	
	
	
I fixed this on Ernie.
	Mark

From mark Tue May 27 23:34:24 1980
To: research!dan v7bugs wh5ess!ber
Subject: fix to uux bug
Cc: wh5ess!teklabs!clemc wh5ess!uwvax!bob

A bug in uux prevents the - option from working with binary files.
To fix it, in uux.c, search for "fputs".  (It's in an if (pipein) {.)
replace the fgets/fputs loop by
		while ((c = getc(stdin)) != EOF)
			putc(c, fpd);
and declare c somewhere to be an int.  (I put the line
		register int c;
right after the if (pipein).)

Fixing this bug will allow the new uusend program, which will be released
shortly, to work, allowing the transfer of binary files across indirect
uucp links.

(I don't know where dan's home machine is, would someone please let
him know about this?)

	Mark

From michael Wed Jun  4 18:21:35 1980
To: v7bugs
Subject: Adb

I have found two bugs in Adb (on the 11 at least)
First I think the floating point registers are not collected properly,
we have no floating point so I havent checked.  It looks to me like
"readregs" in runpcs.c gets the 25 BYTES starting at u.u_fpsr rather
than the 25 words.  Those without an fp unit might want to comment
that section out anyway and make break pointing run faster.
Second in runpcs (same file) the line which has the following fragment:
	... BKPTEXEC, command(bkpt->comm,':')) .....
should be:
	... BKPTEXEC, !command(bkpt->comm,':')) ....
This causes the count in the break point to be used.
Also anyone who has a method of translating adb into readable 'C' should
get a prize.

From michael Mon Jun  9 09:02:14 1980
To: ucsfcgl!tom
Cc: v7bugs

What I should have said about the fp registers is that it is fetching
25 words at 25 byte addresses.  I think that the ptrace call
sould be:
	ptrace(RUREGS,pid,i*2,0) OD

From Cory:root Wed Jun 25 18:17:42 1980
To: kridle
Cc: v:v7bugs

Bob,
I fixed a bug in trap.c that I found when installing V7 on the 11/45.
The case1+USER fuiword should be ((caddr_t)pc-2) and not ((caddr_t)(pc-2)).
You might want to forward this to others who might be interested.
	jeff


From Cory:len Sat Jun 28 13:44:33 1980
To: v:v7bugs

	From root Wed Jun 25 18:14:05 1980
	To: kridle
	Cc: v:v7bugs
	
	Bob,
	I fixed a bug in trap.c that I found when installing V7 on the 11/45.
	The case1+USER fuiword should be ((caddr_t)pc-2) and not ((caddr_t)(pc-2)).
	You might want to forward this to others who might be interested.
		jeff
	


From uucp Sun Jul 20 07:06:17 1980
>From daemon Sun Jul 20 02:28:59 1980 remote from ucsfcgl
>From rusty Fri Jul 18 20:23:26 1980 remote from cmevax
To: ucsfcgl!ucbvax!v7bugs
Subject: learn bug

In file dounit.c insert before the "goto retry;" "fclose(scrin);" otherwise
you can run out of file descriptors if you goto retry enough times, and one
of the fclose's will produce a core.



From michael Fri Aug 29 14:54:47 1980
To: v7bugs
Subject: unix on 11/70's with unibus disks

Unix as released cannot run on an 11/70 without a massbus disk.
A change to the standalone boot code and to UNIX itself is necessary
for this to work.  In standalone/M.s simply change the code so it
does not enable the unibus map:
<	mov	$65,SSR3	/* 22-bit, map, K+U sep */
-----
>	mov	$45,SSR3	/* 22-bit, K+U sep */

This will allow the system to boot.  But strange things happen when
you do raw I/O on a unibus disk.

In conf/mch.s before:
	bit	$20,SSR3
add:
	mov	$65,SSR3

There is similar code farther down, but I think that it doesnt get 
executed....
					mike

From ESVAX:jimbo Wed Sep 17 01:29:39 1980
To: v:v7bugs
Subject: "last" catches interrupts

when forked into the background.


From bill Wed Sep 17 11:56:45 1980
To: ESVAX:jimbo v7bugs
Subject: "last" catches interrupts

there is a cleaned up last in /usr/src/new on csvax.
	bill

From mhtsa!mp Wed Sep 24 06:53:45 1980
To: ucbvax!v7bugs
Subject: floating point bugs
Cc:  mp

You may have heard of these bugs before (the following is quoted verbatim
from Vrije Universiteit's Pascal-VU package, which has been around for awhile),
yet I find that USG's UNIX still has them...

Floating point registers

     When a program is swapped to  disk  if  it  needs  more
     memory,  then  the  floating  point  registers were not
     saved, so that it may have different registers when  it
     is  restarted.   A  small assembly program demonstrates
     this for the status register.   If  the  error  is  not
     fixed,  then  the  program  generates  an IOT error.  A
     "memory fault" is generated if all is fine.

          start:  ldfps   $7400
          1:      stfps   r0
                  mov     r0,-(sp)
                  cmp     r0,$7400
                  beq     1b
                  4

     You have to  dig  into  the  kernel  to  fix  it.   The
     following patch will do:

          /* original /usr/sys/sys/slp.c */

          563             a2 = malloc(coremap, newsize);
          564             if(a2 == NULL) {
          565                     xswap(p, 1, n);
          566                     p->p_flag |= SSWAP;
          567                     qswtch();
          568                     /* no return */
          569             }

          /* modified /usr/sys/sys/slp.c */

          590             a2 = malloc(coremap, newsize);
          591             if(a2 == NULL) {
          592     #ifdef FPBUG
          593                     /*
          594                      * copy floating point register and status,
          595                      * but only if you must switch processes
          596                      */
          597                     if(u.u_fpsaved == 0) {
          598                             savfp(&u.u_fps);
          599                             u.u_fpsaved = 1;
          600                     }
          601     #endif
          602                     xswap(p, 1, n);
          603                     p->p_flag |= SSWAP;
          604                     qswtch();
          605                     /* no return */
          606             }


Floating point registers.

     A similar problem arises when  a  process  forks.   The
     child  will  have random floating point registers as is
     demonstrated  by  the   following   assembly   language
     program.  The child process will die by an IOT trap and
     the father prints the message "child failed".

          exit    = 1.
          fork    = 2.
          write   = 4.
          wait    = 7.

          start:  ldfps   $7400
                  sys     fork
                  br      child
                  sys     wait
                  tst     r1
                  bne     bad
                  stfps   r2
                  cmp     r2,$7400
                  beq     start
                  4
          child:  stfps   r2
                  cmp     r2,$7400
                  beq     ex
                  4
          bad:    clr     r0
                  sys     write;mess;13.
          ex:     clr     r0
                  sys     exit

                  .data
          mess:   <child failed\n>

     The same file slp.c should be patched as follows:

          /* original /usr/sys/sys/slp.c */

          499             /*
          500              * When the resume is executed for the new process,
          501              * here's where it will resume.
          502              */
          503             if (save(u.u_ssav)) {
          504                     sureg();
          505                     return(1);
          506             }
          507             a2 = malloc(coremap, n);
          508             /*
          509              * If there is not enough core for the
          510              * new process, swap out the current process to generate the
          511              * copy.
          512              */

          /* modified /usr/sys/sys/slp.c */

          519             /*
          520              * When the resume is executed for the new process,
          521              * here's where it will resume.
          522              */
          523             if (save(u.u_ssav)) {
          524                     sureg();
          525                     return(1);
          526             }
          527     #ifdef FPBUG
          528             /* copy the floating point registers and status to child */
          529             if(u.u_fpsaved == 0) {
          530                     savfp(&u.u_fps);
          531                     u.u_fpsaved = 1;
          532             }
          533     #endif
          534             a2 = malloc(coremap, n);
          535             /*
          536              * If there is not enough core for the
          537              * new process, swap out the current process to generate the
          538              * copy.
          539              */


From ESVAX:asa Wed Sep 24 13:34:03 1980
To: v:v7bugs
Subject: as: Symbol table overflow

I have gotten a complaint from a user trying to compile a fortran
program. The assembler complains about symbol table overflow.
What can be done about it? What is the size of the symbol table?


From bill Wed Sep 24 16:02:10 1980
To: ESVAX:asa v7bugs
Subject: as: Symbol table overflow

this will be fixed in the next release of the system.
for the time being he should break up the program into pieces.
(there is no fixed limit on symbol table size in the next releasre)