rcodi@yabbie.oz (Ian Donaldson) (07/21/87)
> 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
allbery@ncoast.UUCP (Brandon S. Allbery) (07/26/87)
As quoted from <567@yabbie.oz> by rcodi@yabbie.oz (Ian Donaldson): +--------------- | 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. +--------------- I agree with the first sentence. But anyone who depends on a variable being 0 on program start-up gets what he deserves on an OS that doesn't zero memory or registers. What happens if a variable's zero value isn't a binary zero? (Example: FP on some machines.) Also, the next step is to zero auto variables on function start-up; this strikes me as ridiculous unnecessary overhead. I *always* explicitly initialize variables. This avoids any potential problems with OSes that don't do it for me, or non-binary-zero representations of zero values, etc. It's _safer_. -- Brandon S. Allbery, moderator of comp.sources.misc and comp.binaries.ibm.pc {{harvard,mit-eddie}!necntc,well!hoptoad,sun!cwruecmp!hal}!ncoast!allbery ARPA: necntc!ncoast!allbery@harvard.harvard.edu Fido: 157/502 MCI: BALLBERY <<ncoast Public Access UNIX: +1 216 781 6201 24hrs. 300/1200/2400 baud>>