[net.unix-wizards] 2.8 exec bug fix wanted

greg@isrnix.UUCP (12/17/83)

#N:isrnix:14600002:000:1007
isrnix!greg    Dec 16 13:37:00 1983

    We are running a heavily modified version of UCB 2.8BSD on our
11/44.  I have noticed (as have others running 2.8 on other machines)
that an executable file containing nothing but the 16 byte header and
a magic word (407, 410, ...) will crash the system when executed.  I
should say that as long as the text/data/bss sizes in the header
are 0, the system will bite it.  I have done *some* debugging, but
nothing really substantial.  I >think< that the bug happens when the
system starts up the process - something like the machine faults when
the PC tries to read the first instruction (since the Memory Management
is set up with 0 length segments all around) and the trap code (or somebody
else) tries to find out what went wrong but messes up. Before I go
digging around, has anyone fixed this problem (that is, fixed the REAL
bug, not just put a patch in getxfile to disallow 0 length programs)?

		Thanks,

		Gregory Travis
		ihnp4!inuxc!isrnix!greg
		pur-ee!isrnix!greg
		cbosgd!qusavx!isrnix!greg

jpayne%bbn-vax@sri-unix.UUCP (12/19/83)

From:  Jonathan Payne <jpayne@bbn-vax>

Yes, we found that bug recently.  The fix is in getxfile:

		expand(ds, S_DATA);
		i = ds;
		while (--i)
			clearseg(u.u_procp->p_daddr + i);

Change the "while (--i)" to "while (--i > 0)"

edler@cmcl2.UUCP (12/21/83)

#R:isrnix:14600002:cmcl2:5000003:000:694
cmcl2!edler    Dec 21 13:22:00 1983

Also watch out for programs doing "brk(0);".  On at least some versions
of unix for pdp11s without floating point hardware, this crashes
the system.  The problem is that there are some references to the
(non-existant) floating point registers in the kernel routine backup(),
and they cause a panic.  For some reason that was never clear to me,
they don't seem to get executed in normal practice, but brk(0) will do it.
A fix is to remove the offending instructions (at the location
of the pc printed by the panic).  Is there anyone that has taken the
time to understand backup() more completely, and can they say if this
is an ok fix?

	Jan Edler	cmcl2!edler	(New York University)
			edler@nyu