gurgle@well.sf.ca.us (Pete Gontier) (12/18/90)
In article <1CE00001.66qcvx@tbomb.ice.com> time@tbomb.ice.com writes: >I am implementing the trap call in Assembler, and Inside Mac Vol II >page 42 clearly states that d0 returns a result code. However, I did >not make the logical leap to see that the Pascal call (shown just >above the assembler comment :) was a procedure. 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? -- Pete Gontier, gurgle@well.sf.ca.us Software Imagineer, Kiwi Software, Inc.
time@tbomb.ice.com (Tim Endres) (12/18/90)
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.
urlichs@smurf.sub.org (Matthias Urlichs) (12/19/90)
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)/keith@Apple.COM (Keith Rollin) (12/19/90)
In article <1CE00001.1p63kl@tbomb.ice.com> time@tbomb.ice.com writes: > >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, "dw xxxx" should work fine in Macsbug. "dw" stands for Display Word. Also, I think that this whole thing with MemErr getting set to zero was the result of a bug in MacsBug. Macsbug would make a call to the Graphics Device Manager, which would make a call to the Memory Manager, which would set MemErr. Therefore, it was Macsbug that was clearing MemErr. I'm not sure what versions of Macsbug suffer from the bug. BTW: I don't know if this is true about SetGrowZone specifically, but on all ROMs subsequent to the 64K ROMs, the Memory Manager sets MemErr itself. Previously, this was done by the high-level glue provided by the development system. In MPW 3.2, this glue has been taken out, along with support for the 64K ROMs. -- ------------------------------------------------------------------------------ Keith Rollin --- Apple Computer, Inc. --- Developer Technical Support INTERNET: keith@apple.com UUCP: {decwrl, hoptoad, nsc, sun, amdahl}!apple!keith "Argue for your Apple, and sure enough, it's yours" - Keith Rollin, Contusions