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