KON & BAL'S PUZZLE PAGE

WHEN MAPS GO BAD

KONSTANTIN OTHMER AND BRUCE LEAK

See if you can solve this programming puzzle, presented in the form of a dialogbetween Konstantin Othmer (KON) and Bruce Leak (BAL). The dialog gives cluesto help you. Keep guessing until you're done; your score is the number to the left ofthe clue that gave you the correct answer. These problems are supposed to be tough. If you don't get a high score, at least you'll learn interesting Macintosh trivia.

KON: I have a Macintosh IIfx at home with a 13-inch color monitor and an old Kong.

BAL You mean the black-and-white two-page display? That thing is out of production. Programmers were the only ones who bought it, and we already sold one to every Macintosh programmer. I've got one too.

KON Mine's probably older, though. Fung gave me one of the prototype units that were blocking the entrance to his office about five years ago.

BAL Does it have the stylish metal cheese grater cage around it or did you actually get a plastic case?

KON I scored one with plastic, though it's yellow now from sitting in the sun. Anyway, now that the PowerPC workload is finally winding down, I've actually spent some time at home. I started playing around with Darryl's mapping program on my fx.

BAL MacAtlas?

KON Yeah. It's pretty cool. The problem is I can't open files.

BAL Command-O open? What happens?

KON Nothing. No Standard File, no dancing bears -- it's as if I never gave the Open command.

BAL I've never had a problem with that program. Does the menu get highlighted?

KON Yeah. Every once in a while you'll see it flash. This problem happens systemwide; I can't even open files in ResEdit.

BAL Can you drag documents onto the application icon in the Finder to open them?

KON Yeah. Everything not related to Standard File seems to work fine. I can edit files, play movies -- even file sharing works.

BAL What version of the system are you running? Does printing work?

100 KON I'm running System 7.1. I can't save and then print as recommended by our print shop because there's a problem with Standard File, but other than that it works fine. Why?

BAL This one's easy, KON. Something is locked down in your MultiFinder heap, so your system heap can't grow. Standard File can't bring in all its resources, so it punts. Are you running that skanky StockItToMe server that Timo and Rubinowitz wrote?

90 KON This happens just after boot and I've got mounds of RAM now that I've removed DAL. I do a heap dump (hd) of the MultiFinder heap and there are no locked blocks at the bottom, so the system heap can grow all it wants. Furthermore, the heap total (ht) command shows that there's plenty of room in the system heap.

BAL Clearly this bug is limited to your home machine. I figure you have some slimy KON code on there that's only half debugged -- maybe a beta version of WonderPrint. Set an ATB on Standard File, 'PACK' 3, and then try to open a document.

80 KON I hit the A-trap, but when I trace over it it just returns without putting up the Standard File dialog.

BAL Is the package getting loaded?

70 KON Yeah.

BAL Since I don't have the source to Standard File handy, I'll use the log command and then the conditional step command to get a trace of all the instructions executed inside the package. I figure it should be fairly easy to spot some error condition where the code decides to bail. Since the _Pack3 instruction is two bytes, if the call to it is at the current PC address, I use the MacsBug commands

log MyStdFileLog
s pc=pc+2

to step, logging each instruction to a file and then stopping as soon as the trap is exited.

60 KON Wow, that conditional stepping is pretty cool. I didn't know MacsBug was that sophisticated. You could have just put a breakpoint on the other side of the _Pack3 and stepped a zillion instructions. Anyway, the trace isn't prohibitively long. Standard File preloads all the resources it needs to display the dialog, checking each one to see if it was loaded properly. When it tries to load LDEF -4000, it fails and bails.

BAL All the resources it needs must come from the System file. Check to see if LDEF - 4000 exists in the system.

55 KON According to ResEdit, the LDEF isn't present in the System file.

BAL Compare the LDEFs in your system with a fresh installation.

50 KON The LDEFs are all the same except one, which has a different resource ID.

BAL Well, it sounds like you've got a trashed System file. Copy and paste the bad LDEF into your system and reboot.

45 KON Everything works fine now, but if I drag-install a new system, Standard File fails. Fixing the LDEF is addressing the symptom, not the problem.

BAL You drag the good System file over and reboot, and Standard File is broken again?

KON Yep.

BAL Check the LDEF with ResEdit.

40 KON It's renumbered again.

BAL So something is trashing the resource map during boot. What if I boot with the Shift key held down to disable extension loading?

35 KON According to ResEdit, the resource map is still trashed.

BAL Try dumping resources of type 'LDEF' with the command rd LDEF at interesting times during the boot process.

30 KON If you hold down the Control key to enter MacsBug just after it's installed, the LDEF resources are fine. If you check it again when you're in the Finder, the LDEF is bad.

BAL So I use

atb hopenresfile ';dm @(sp+2);rd LDEF;g 

to watch extensions load during the boot process. The command breaks as each
extension is loaded and displays the name of the extension and the current state of all
LDEF resources. When I see the LDEF go bad, I've gone a long way toward finding
the offending code.

KON During the 7.1 boot process, the system patches are loaded from disk and installed.
One of those patches opens all the font files in that crazy font folder. After all the
patches are installed, the system extensions
are loaded, starting with the 8*24 GC card. It's loaded first so that QuickDraw is in a
well-defined state before other system extensions go and patch out the world; once
third parties start getting in there, it's a free-for-all.

BAL Obviously, all the system patches need to be installed before extensions are loaded so
that the extensions can take advantage of improvements provided by the patches.
Haven't you ever wondered why booting takes so long?

25 KON While the font files are being opened, the resource map is fine. But just before the
first extension is loaded, the resource map is bad.

BAL We need to narrow down where the map is going bad. I'll look through the system
map for the ID that's getting stepped on. First I get the size of the resource map
handle by using

wh @@sysmaphndl 

Then I can find the resource ID with

f @@sysmaphndl size f060

since F060 is hex for -4000, the resource ID that's getting smashed.

20 KON Good try, but you find seven occurrences.

BAL So I continue until the map goes bad, and check for -4000 again. I'll find the one that's changed, reboot, and step-spy on that address. Ta-da!

15 KON Sorry, but the resource map is a handle and it has moved on you. You can identify the one that's changed, but you can't step-spy on it since it's moving around all the time.

BAL Fine. I'll reboot in 24-bit mode, lock the handle down by setting the high bit of the resource map handle's master pointer, and step-spy on the address. Over.

10 KON Now Standard File works fine, but file sharing is starting to act flaky.

BAL OK. So I'm going to have to brute force it. I'll break when the last font loads. I'll log the MacsBug output to a file with log myLDEFFile and then atb ';rd LDEF;g to break on all traps and dump all the LDEF resources. I'll also do anatc hopenresfile and then an atb hopenresfile to clear the rd LDEF;g when HOpenResFile is hit. This way we'll fall into MacsBug when the first INIT is opened. Then I'll let it rip and get some lunch.

5 KON Pretty snazzy there, BAL. Before the map goes bad you see a bunch of Slot Manager calls and control calls. The last trap that gets called before the map goes bad is a control call to the driver which seems to originate from within InitGDevice.

BAL Hmmm. We're at secondary INIT time. The driver gets called again since all the system patches are now loaded. We added this because monitors boot back to the same configuration they were in when the machine was shut down. With 32-Bit QuickDraw, the machine could have been shut down in 32-bit video mode, so the driver needs to be called a second time after the system patches (where 32-Bit QuickDraw lives) are loaded.

KON Yeah, the call that's killing the map is a call to the driver to set the bit depth. At secondary INIT time the 'scrn' resource is read to find out what the last bit depth was, and each device is called to set the depth up properly.

BAL The call must be going to the bogus Kong video card Fung gave you. What's the ROM version on that thing?

KON It's a beta ROM. When I asked Mike Puckett about it he said there was some nasty "fungus" in the code, and that it was fixed before final. He gave me a new video ROM, and now everything works great. Real-world users would never experience this, of course, since the problem was corrected long before the card went out.

BAL You and Van Brink should share packrat stories. You never know, some of that old equipment might become collector's items some day.

KON This problem began when I started using MacAtlas because I switched my Kong into grayscale mode. My system is a lot more stable now that those spurious writes have been fixed. Before I tracked this bug down, I was having intermittent problems.

BAL Nasty.

KON Yeah.

KONSTANTIN OTHMER AND BRUCE LEAK regularly change their AppleLink addresses through various front companies to help defray their tax losses from dealings in the stock market. They're currently trying to corner the market on masked ROMs, particularly 680x0 ROMs targeted at PowerPC processor-based machines. They were last seen looking for a '57 Corvette in good condition and are willing to swap debugging services in trade. *

SCORING

• 80-100 This is a special category reserved for Waldemar and Jasik.
• 50-70 Weekends spent at Weird Stuff Warehouse or Van Brink's garage are starting to pay off.
• 25-45 You're spending too much time playing with that 3DO interactive multiplayer machine at your local electronics store.
• 5-20 You're spending too much time at the gym. *

Thanks to Peter Hoddie, Brian McGhie, and Mike Puckett for reviewing this column. *