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