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
Thanks to Peter Hoddie, Brian McGhie, and Mike Puckett for reviewing this column.
*