Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!ira.uka.de!smurf!urlichs From: urlichs@smurf.sub.org (Matthias Urlichs) Newsgroups: comp.sys.mac.programmer Subject: Re: MemErr and SetGrowZone on IIci Message-ID: Date: 18 Dec 90 23:46:41 GMT References: <22228@well.sf.ca.us> Organization: University of Karlsruhe, FRG Lines: 24 In comp.sys.mac.programmer, article <22228@well.sf.ca.us>, gurgle@well.sf.ca.us (Pete Gontier) writes: < < In (thinly) related news, we spent hours trying to track down the misbehavior < of the low memory global MemErr after a call to SetGrowZone. We had < in MacsBug, the instruction 'TST.W MemErr' listed. We'd do a 'dw MemErr' and < get an error code we'd never seen before and wasn't listed anywhere. After < single-stepping the TST, we'd do another 'dw MemErr' and it would turn < out to have CHANGED to 0. We finally decided that on the IIci, there < was something wrong with the MMU, because this behavior did not appear on < other machines. Anybody ever seen or heard of anything like this? Yes -- some extremely brain-dead INIT patched a trap which ordinarily doesn't move memory (well, it did after that trap patch. :-( MemError was of course being stuffed into by that INIT's glue code), and another INIT insisted on installing a VBL which used that trap. Time for various very spurious and totally inexplicable bugs, including positive(!) memory manager error codes. I forget what INIT that was; I'd probably remember if anyone tries to convince me to use it, however. (This already happened...) -- Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de /(o\ Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49+721+621127(0700-2330) \o)/