laf@mbunix.mitre.org (Lee Fyock) (01/08/91)
How do you use Macbugs' heapscramble ("hs")? I was running a THINK C project,
ran it to get to the debugger, dropped into macsbug, turned on heapscramble,
came back to the debugger and stepped on the line
InitGraf(&thePort);
whereupon I was dropped back into macsbug with a message about macsbug causing
the error...
The program runs quite well; I was checking my locks and unlocks. How is
heapscramble intended to be used?
Thanks for any info,
Lee Fyock
laf@mbunix.mitre.orgksand@Apple.COM (Kent Sandvik) (01/10/91)
In article <127599@linus.mitre.org> laf@mbunix.mitre.org (Lee Fyock) writes: >How do you use Macbugs' heapscramble ("hs")? I was running a THINK C project, >ran it to get to the debugger, dropped into macsbug, turned on heapscramble, >came back to the debugger and stepped on the line >InitGraf(&thePort); >whereupon I was dropped back into macsbug with a message about macsbug causing >the error... >The program runs quite well; I was checking my locks and unlocks. How is >heapscramble intended to be used? When you turn heap scrambling on, all the *relocatable* memory blocks in the heap will be moved (if possible) as part of the Memory Manager compaction scheme. This happens with traps such as NewPtr, NewHandle, ReAllocHandle, SetPtrSize, or SetHandleSize. Now if the heap is checked just before the scrambling, and if the heap is currupted you drop down to MacsBug with an error message telling of this. In a way 'hs' is a tool to enforce the worst-case situation in the heap, because programs should not break during heap compaction. If you have problems, check for things like dereferenced handle problems, or any other invalid handle cases. Hope this helps. Kent Sandvik, MacDTS -- Kent Sandvik, Apple Computer Inc, Developer Technical Support NET:ksand@apple.com, AppleLink: KSAND DISCLAIMER: Private mumbo-jumbo Zippy++ says: "C++, anything less is BCPL..."
jimo@phred.UUCP (Jim Osborn) (01/16/91)
laf@mbunix.mitre.org (Lee Fyock) writes: >How do you use Macbugs' heapscramble ("hs")? >... >came back to the debugger and stepped on the line: > InitGraf(&thePort); >whereupon I was dropped back into macsbug... I've had the same experience, seeming to imply memory-handling problems in the toolbox calls. Could these "errors" be caused by being close to (or barely over) the limits for memory? I'm trying to work on an old 2 Meg Mac II. My application uses a full-screen offscreen PixMap and if I try to Run from Think C with the Set-Project-Type memory size less than 500K I quit with an "Out of Memory" message. If I try to set Think C's allocation to less than 700K I get the "Out of Memory" message when I try to compile. In any case, even with its 700K Think C trips MacsBug if I've ever turned on heapscramble since the last reboot. I assume this means that Think C is misbehaving somehow, but of course I don't have control over that. How can I turn heapscramble back OFF so that I can use the compiler again? Surely we aren't meant to reboot after every heapscramble test, are we? -- pilchuck!jimo@phred Jim Osborn, Physio Control Corp 11811 Willows Rd, Redmond, WA, 98073 206-867-4704 direct to my desk