Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!umich!ox.com!tbomb.ice.com!time
From: time@tbomb.ice.com (Tim Endres)
Newsgroups: comp.sys.mac.programmer
Subject: Re: MemErr and SetGrowZone on IIci
Message-ID: <1CE00001.1p63kl@tbomb.ice.com>
Date: 18 Dec 90 11:38:13 GMT
Reply-To: time@tbomb.ice.com
Organization: ICE Engineering, Inc.
Lines: 26
X-Mailer: uAccess - Mac Release: 1.0.3


In 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

This error code was nothing of the sort. It is a pointer to something
and when looked at as a short appears to be a boagus error code.

> 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?

I presume you meant 'dm MemErr' (MacsBug right?). The MemErr global
is set by the glue code used to implement the SetGrowZone() in your
high level language (MPW or Think?). Why the TST.W would affect this
MemErr value I do not know, unless you missed some other code hitting
it. Sounds like you stepped right through the one instruction properly,
so it does sound a little wierd. Maybe, because the glue code is supposed
to treat this as a procedure (no return value) it is setting MemErr
to noErr to clean up.

tim.