spencer@eecs.umich.edu (Spencer W. Thomas) (04/04/91)
I've been having intermittent crashes on my Plus since I upgraded to 6.0.7 (perhaps foolishly seeking new sound capabilities). I eventually tracked it down to the value at location 222 getting smashed. Tmon says that the name of this location is "JFigTrkS" (to 8 characters) but I can't find a reference to such a global in my 5 volumes of IM. Today, I set a trap-checksum on this location, and it got stomped by PrintMonitor in a piece of code that didn't come anywhere near it!. It was presumably ok at a MoveHHi (invoked on a handle in the system heap), and had been stomped on 3 instructions later at an HLock. The intervening instructions put the argument for the HLock into A0. So, I'm still baffled. Some questions: Could the MoveHHi have done it? The preceding word at 220 is MemError. However, the MoveHHi seems to have succeeded (the memory block in question ended up right at the top of the system heap), and presumably it wouldn't have written 4 bytes of data into the 2 byte MemError, anyway. Should I suspect a VBL task that "sneaked in"? This is worse, because it would be so much harder to track down. However, if any VBL code did any A traps after the change to 222, my checksum trap would have found it then, not later back in PrintMonitor (I think...). Besides, it has happened a couple of times, right at the same place. What is this global used for, anyway? Does any system before 6.0.7 use it? When I booted up a 6.0.5 system from floppy, it had a different, apparently bogus value in it. Should I just switch back to 6.0.5, which never seemed to do this? -- =Spencer W. Thomas EECS Dept, U of Michigan, Ann Arbor, MI 48109 spencer@eecs.umich.edu 313-936-2616 (8-6 E[SD]T M-F)
spencer@eecs.umich.edu (Spencer W. Thomas) (04/04/91)
More information: location 222 is indeed getting wiped by MoveHHi. There is a patch that says, in part, MOVEQ #$00,D0 MOVE.L D0,$0220 The last line should be, I submit, MOVE.W D0,$0220 I'm still investigating. -- =Spencer W. Thomas EECS Dept, U of Michigan, Ann Arbor, MI 48109 spencer@eecs.umich.edu 313-936-2616 (8-6 E[SD]T M-F)
spencer@eecs.umich.edu (Spencer W. Thomas) (04/04/91)
More on the location 222 bashing. The culprit is.... Multifinder 6.1b9! Why I never (as far as I know) had this problem before installing 6.0.7, I don't know. To fix, use a reputable disk editing program (I used Norton Disk Editor), search for (hex) 21C00220 and change it to 31c00220. No more crashes. Oh, information received is that the longword at 222 is jFigTrkSpd, and is part of the floppy driver. That fits -- I would always get that crash when inserting a floppy. -- =Spencer W. Thomas EECS Dept, U of Michigan, Ann Arbor, MI 48109 spencer@eecs.umich.edu 313-936-2616 (8-6 E[SD]T M-F)
ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) (04/07/91)
This zapping of $222 by MoveHHi is documented in my System 6.0.7 release notes as one of the bugs *fixed* in MultiFinder 6.0.7. Are you running MultiFinder 6.1b9, by any chance? Lawrence D'Oliveiro fone: +64-71-562-889 Computer Services Dept fax: +64-71-384-066 University of Waikato electric mail: ldo@waikato.ac.nz Hamilton, New Zealand 37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00 It's not a bug. This capability is merely inoperative.