Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!munnari!moncskermit!goanna!yabbie!rcodi
From: rcodi@yabbie.oz (Ian Donaldson)
Newsgroups: comp.unix.wizards
Subject: Non repeatable behaviour on Vax 4.2bsd [was: Re: non repeatable, 4.3 C compiler behavior]
Message-ID: <567@yabbie.oz>
Date: Mon, 20-Jul-87 20:45:22 EDT
Article-I.D.: yabbie.567
Posted: Mon Jul 20 20:45:22 1987
Date-Received: Fri, 24-Jul-87 03:13:17 EDT
References: <328@rocksanne.UUCP>
Organization: RMIT Comm & Elec Eng, Melbourne, Australia.
Lines: 53

> I have been having the following, rather bizzare, problem with the 4.3bsd
> C compiler.  I get non repeatable compiler errors!  By non repeatable I
> mean that if I reissue the same command, I will get a different error
> or a successful compile.  The errors are usually of the form:

[ verbose description suppressed ]

Non reapeatable errors are usually attributed to one of:

    1: hardware fault (possible, easy to check, usually)
    2: timing problems (not likely with a C compiler)
    3: the environment of the process is not sufficiently insulated
       from the external environment (highly likely)

Number #3 most often is due to differing environment variables, but...

One day I noticed in our VAX 4.2bsd kernel (on a VAX 750) that the piece
of code in setregs() in the kernel that initializes all the CPU
registers to zero on an exec(2) is commented out.  

This is absolutely disgusting!

The only reason I can see for this is that when booting the system,
the boot parameters are passed in r11 to /etc/init.  Equally disgusting!
It also makes /etc/init machine dependent.

[ On our 68k 4.1bsd machines we cleaned all this up and the boot parameters
  are passed as string arguments as (argc,argv) (like every other program)
  to /etc/init and /etc/rc from the monitor or from the reboot(8) command. 
  All the registers are initialized to zero, except pc and sp for obvious
  reasons]

There is nothing worse than trying to debug a piece of software
that *sometimes fails* when given the same input in successive runs.
Any system that doesn't initialize core on process start falls
into this category.  

Not initializing registers is in the same boat, though generally not as 
serious, because there are not many of them, and are likely to be clobbered 
quickly in program execution, but due to the VAX (and many other) conventions
on register preservation that the C compiler uses (ie: save all the
registers you are going to clobber in a routine, and preserve them on
exit -- except a list of designated scratch registers) the 
uninitialised register contents can concievably linger for some time.

What it boils down to in your case is probably an uninitialized register
variable somewhere.  Good luck in finding it.  Try linting the C compiler.

Does Vax 4.3bsd initialize its registers to zero??
Are there other UNIX 4.[23] kernels that don't initialize their
registers to zero?   Heaven forbid!

Ian D