home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!charon.amdahl.com!pacbell.com!mips!darwin.sura.net!zaphod.mps.ohio-state.edu!rpi!bu.edu!dartvax!Mark.R.Valence
- From: Mark.R.Valence@dartmouth.edu (Mark R. Valence)
- Newsgroups: comp.sys.mac.programmer
- Subject: Re: Checksumming MemErr global variable (Tech Note 7) problem
- Message-ID: <1992Aug19.145956.810@dartvax.dartmouth.edu>
- Date: 19 Aug 92 14:59:56 GMT
- References: <1992Aug18.181714.12276@midway.uchicago.edu>
- <Bt74v9.KGF@taligent.com>
- Sender: news@dartvax.dartmouth.edu (The News Manager)
- Organization: Dartmouth College, Hanover, NH
- Lines: 26
-
- In article <1992Aug18.181714.12276@midway.uchicago.edu>,
- chh9@quads.uchicago.edu
- (Conrad Halton Halling) writes:
- > I tried this, but apparently StripAddress() is using MemErr because it
- > is stuffing strange numbers into this global variable, so this technique
-
- I think MacsBug is causing some confusion here. You are not looking at
- the code for StripAddress, but rather at some unnamed code in ROM.
- MacsBug likes to display routine names in ROM. It figures out the name
- for a given chunk of code by looking in the trap tables and determining
- the nearest ROM routine above the given address(es). So, since there
- is a bunch of internal ROM code immediately after StripAddress, it all
- gets grouped under the StripAddress routine label.
-
- Of course this is a glossed over explanation, but you get the picture.
- Oh, and StrippAddress might not be the only routine that gains this
- extra code. Oh, and on some ROMs (past or future), StrippAddress might
- not gain any extra code. Its all so ROM specific you see.
-
- The upshot is, StripAddress is not cramming anything into MemErr, it's
- some other Trap, which calls some internal routine, and is probably
- stuffing a real honest-to-goodness memory error into MemErr. Then when
- the internal routine exits, the caller will see the error, and use the
- stack for its memory needs instead :-)
-
- Mark.
-