Path: utzoo!utgpu!attcan!uunet!lll-winken!lll-ncis!helios.ee.lbl.gov!pasteur!ucbvax!hoptoad!tim From: tim@hoptoad.uucp (Tim Maroney) Newsgroups: comp.sys.mac.programmer Subject: Re: Stack manipulation problems Message-ID: <6180@hoptoad.uucp> Date: 6 Jan 89 10:07:23 GMT References: Reply-To: tim@hoptoad.UUCP (Tim Maroney) Organization: Eclectic Software, San Francisco Lines: 47 In article bob@xanadu.COM (Bob Schumaker) writes: >We are in the process of implementing a multi-tasking executive and we are >running into a problem when we move the stack. The premise is that we >can allocate some storage in the heap, make the stack pointer point >to this storage (after setting up A6 and then copying the stack frame) >and restarting execution with the new values (using setjmp/longjmp under >LSC 3.01p3). > >As soon as the stack pointer and A6 contain the new values, the Mac >environment behaves strangely -- the menus highlight with a black >rectangle (no highlighted text shows) and/or the text disappears from >the menus. Things get progressively weirder from there. Clearly data in the heap are getting overwritten, therefore you are not leaving enough space for the stack. Bear in mind that the Mac OS has only one stack -- OS interrupt-driven code will run on whatever the current SP is set to, as will desk accessories if you give them time. Make sure you have left at least 8K of stack space. Check this by using MacsBug's heap check function. If you are overwriting heap data belonging to other blocks, the heap checker will almost surely give an error. I assume you have remembered that 68K stacks grow downwards, so you need to set the SP to the *end* of the block you've allocated, that is, the highest address, not the lowest address. (Actually it should be set to the highest address minus four bytes.) >As a check, we just copied the stack frame (using the same method) several K >below the stack pointer (unused memory between the heap and the stack) and >set up all the appropriate registers in an identical fashion -- and >everything worked just fine! Move the stack away from the heap and you're pretty darned unlikely to overwrite other data in the heap. >Does anyone out there have any idea what's going on? The only thing that >we can figure is that somewhere in the Mac system software, some routine >cares where the stack is -- someone that is, besides the stack sniffer, >which *should* be disabled at this point... "Looking for bugs in all the wrong places...." The menu manager problems indicate that the menu manager heap data structures are getting trashed. -- Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim "Please help support the moratorium on meaningless quotes in .signatures." -- Doug Asherman on rec.music.cd