Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84 SMI; site sun.uucp Path: utzoo!watmath!clyde!burl!ulysses!ucbvax!decvax!decwrl!sun!guy From: guy@sun.uucp (Guy Harris) Newsgroups: net.unix-wizards Subject: Re: Bourne shell's wacky memory allocation Message-ID: <2937@sun.uucp> Date: Sat, 26-Oct-85 19:23:44 EST Article-I.D.: sun.2937 Posted: Sat Oct 26 19:23:44 1985 Date-Received: Mon, 28-Oct-85 04:17:54 EST References: <482@phri.UUCP> <2887@sun.uucp> <531@moncol.UUCP> <5242@elsie.UUCP> <537@moncol.UUCP> <2918@sun.uucp> <2379@brl-tgr.ARPA> Organization: Sun Microsystems, Inc. Lines: 48 > This is real easy to fix. I know - I had to fix it here; I did so by doing the "setbrk" directly instead of faking a SIGSEGV. (The code in question - added to the shell - was allocating some BMF structures, and I didn't feel like having the shell keep bumping its data space up until it got big enough). Your line numbers may differ. This is for the S5R2 shell. It's probably similar for others. *** /tmp/da6483 Sat Oct 26 15:17:15 1985 --- blok.c Thu Oct 10 18:20:49 1985 *************** *** 87,92 reqd &= ~(brkincr - 1); blokp = bloktop; bloktop = bloktop->word = (struct blk *)(Rcheat(bloktop) + reqd); bloktop->word = (struct blk *)(brkbegin + 1); { register char *stakadr = (char *)(bloktop + 2); --- 87,95 ----- reqd &= ~(brkincr - 1); blokp = bloktop; bloktop = bloktop->word = (struct blk *)(Rcheat(bloktop) + reqd); + reqd = (char *)(&bloktop->word) - brkend; + if (reqd > 0 && setbrk(reqd) == (char *)-1) + error(nospace); bloktop->word = (struct blk *)(brkbegin + 1); { register char *stakadr = (char *)(bloktop + 2); The reason why this causes problems on 68010s is not that you can't continue from an instruction. The problem is that you can't do so *from user mode* without kernel hacks. In order to continue the instruction, the "stack puke" (as Henry Spencer described it) must be on the stack when the RTE is done. The RTE must be done from the kernel, since it's privileged. In some UNIXes, returning from a signal doesn't involve the kernel (you can do an RTR to reload the condition codes) - you're out of luck there. In others (like 4.2BSD, which has to reenable the signal in question) returning from a signal requires you to pass through the kernel. However, the bus error frame isn't likely to be on the kernel stack anymore. You'd have to squirrel it away somewhere - somewhere inaccessible to the user, because I don't think Motorola tells you 1) that it won't kill the system if you RTE with arbitrary bits or 2) how to make sure that a bus error frame is safe. Sun UNIX doesn't do this, and other 68010 UNIXes may not either. Guy Harris