March 96 - KON & BAL'S PUZZLE PAGE: Printing, Patching, and Fonts
KON & BAL'S PUZZLE PAGE:
Printing, Patching, and Fonts
Dave Hersey and Cameron Esfahani
See if you can solve this programming puzzle, presented in the form of a dialog
between guest puzzlers Dave Hersey and Cameron Esfahani (cam). The dialog gives
clues to help you. Keep guessing until you're done; your score is the number to
the left of the clue that gave you the correct answer. Even if you never run
into the particular problems being solved here, you'll learn some valuable
debugging techniques that will help you solve your own programming conundrums.
Dave Hey cam, it's kinda quiet. Where are KON and BAL?
cam Since the local salad bar closed, I haven't seen KON. BAL disappeared
after he left the video game industry. Have you been getting enough sleep? You
Dave I've been under a lot of pressure to track down this bug.
cam Maybe I can help. What's the problem?
Dave I have a Power Mac 6100/66 running System 7.5 with QuickDraw GX 1.1. When
I try to print from a word processor, I get the message "The application has
unexpectedly quit, because an error of type 11 occurred." What's an error of
cam That's an unhandled exception from native code. What word processor are
Dave Um, a very large one in a very large office suite from a very large
company up north.
cam Have you updated to version 1.1.3 of QuickDraw GX?
Dave Yeah. The problem still happens.
cam Does it happen on any other machine?
Dave Yes. It crashes on any Power Mac but works fine on 680x0 machines.
cam Hmm. Is the word processor native on the Power Mac?
Dave Yes -- it's fat.
cam It sure is. But I have the same version of system software and the same
word processor, yet my machine doesn't crash.
Dave Well, I have a standard system installed, but I added a bunch of whizzy
cam If I install one of your fonts, will my machine crash?
Dave Sometimes. If you install all my fonts, it crashes all the time.
cam That's easy, then: bad fonts. Here, take out this Thingamajigs font.
Dave No way, man. This is a standard bitmap-only font. It should work. Ike's
machine doesn't have Thingamajigs on it and his machine still crashes.
cam Does he have bitmap-only fonts installed?
cam At what point in the printing process do you crash?
Dave The crash occurs just as the application starts spooling the print
cam Is this word processor QuickDraw GX-aware?
Dave Yes. It has support for the new QuickDraw GX print dialogs, and it calls
the QuickDraw GX translator to translate QuickDraw drawing commands into
QuickDraw GX shapes during printing.
cam Good for them. Have you tried to reproduce the crash with other QuickDraw
Dave Yup. I tried to reproduce it with several QuickDraw GX-aware and
QuickDraw GX-savvy applications. No luck.
cam Try running the 680x0 version of this program on your Power Mac. It will
be slow and piggy, but try it anyway.
Dave The problem went away! So, the crash seems to have something to do with
the PowerPC code in this application.
cam Hmm. Let's install MacsBug and take a look at this from the debugger.
Dave I tried that before, but I couldn't see any symbols in the PowerPC code
where it crashes. I couldn't tell which routine the PC was in.
cam You should install the new version of MacsBug. Version 6.5.2 understands
native exceptions and can use embedded symbols.
Dave Nifty. . . . OK, I've done that. But I still crash.
cam Why do you crash? Type how.
Dave MacsBug claims that there was a "PowerPC access exception at 001DB030
cam What does ConstructNFNTDirectory do? Hey, wait, there's Alex Beaman. Alex,
can you help us out here?
Alex Sure. QuickDraw GX views all fonts as type 'sfnt'. It's really elegant:
ConstructNFNTDirectory will make an NFNT font appear to have an 'sfnt'
directory. It can build either just the directory header or the entire
directory, and this is controlled by a Boolean parameter passed into the
function. OK, gotta run!
Dave Thanks, Alex. When I disassemble ConstructNFNTDirectory with MacsBug, I
Disassembling PowerPC code from ConstructNFNTDirectory
+00000 001DAD7C stmw r14,-0x0048(SP)
+00004 001DAD80 mflr r0
+00008 001DAD84 clrlwi r27,r5,0x18
+0000C 001DAD88 addi r28,r3,0x0000
+00010 001DAD8C mfcr r12
+00060 001DADDC addi r3,r30,0x0000
+00064 001DADE0 addi r4,r28,0x0000
+00068 001DADE4 bl GetNoLoadResource
+000E4 001DAE60 addi r3,r20,0x0000
+000E8 001DAE64 bl ComputeSearchFields
+000EC 001DAE68 crmove cr7_SO,cr7_SO
+000F0 001DAE6C cmpwi cr2,r27,0x0000
+002B4 001DB030 *lwzx r5,r19,r5
+002F0 001DB06C lhz r5,0x0004(r20)
+002F4 001DB070 li r16,0x0001
+002F8 001DB074 addic r5,r5,0x0001
+002FC 001DB078 sth r5,0x0004(r20)
+00300 001DB07C beq cr2,ConstructNFNTDirectory+00324
+003C8 001DB144 addic SP,SP,0x00A0
+003CC 001DB148 mtcrf 0x38,r12
+003D0 001DB14C mtlr r0
+003D4 001DB150 lmw r16,-0x0040(SP)
+003D8 001DB154 blr
An access exception means we're trying to read or write to an invalid
address. That, of course, could be caused by many things, such as uninitialized
variables or trashed memory. Let's check the heaps with hc
Dave Both the system heap and the application heap are fine.
cam OK, I restart the program and use brp in MacsBug to set a breakpoint at
ConstructNFNTDirectory. brp is just like br, except it works for PowerPC code.
After I start printing and the breakpoint is hit, I step through this function
to follow the code flow.
Dave At offset 0x0300 you don't take that branch, and you eventually begin
executing code that will corrupt the QuickDraw GX heap.
cam But that's wrong -- we should've taken that branch. The caller didn't ask
ConstructNFNTDirectory to create the entire directory, just its header; it
didn't allocate enough space for all of it. Check the heaps again.
Dave The heaps seem fine. QuickDraw GX allocates out of its own heap, which
MacsBug doesn't know about. Even if it did know about it, it wouldn't be able
to tell us if the heap was corrupt, as QuickDraw GX has its own memory
cam Darn, memory corruption bugs are the worst. You can trash memory and not
see the effects of it until you're miles away from that code. OK, why didn't it
take the branch at offset 0x0300?
Dave Well, CR2 is true, so the branch won't be taken.
cam How can you tell that CR2 is true?
Dave The PowerPC chip has eight condition register fields, CR0 through CR7,
stored in nibbles in a 32-bit condition register (Dave Evans talked about this
in his column in develop Issue 21). So the value of CR2 would be bits 8 through
11 of the condition register. The chip has its bits numbered from 0 through 31,
from left to right. We can tell that CR2 contains a true value because its
second logical bit isn't set. That bit corresponds to the equals operator, so
the fact that it's 0 means the operation that set this register was not
cam Who sets up CR2?
Dave The code at offset 0x00F0. As Alex mentioned, one of the parameters to
this function is a Boolean that controls whether the whole directory is created
or only the header. Because this parameter is a Boolean, the PowerPC processor
can just compare it against 0 and use the result as a flag for later branches.
Parameters passed in PowerPC code are put from left to right into registers R3
through R10; since this parameter is the third parameter to the function, it's
passed to the routine in register R5. (A much better description of this is in
Inside Macintosh: PowerPC System Software.)
cam I love this chip. I'll reexecute the program and get back to the start of
this function and examine CR2.
Dave It starts out false.
cam So someone's trashing it along the way. Well, we can't use some of our
normal tricks for detecting when memory gets trashed. One problem is that step
spy doesn't work yet for PowerPC. Another problem is that we would want to step
spy on CR2, which is a register, and step spy never worked on registers. We'll
have to do this the hard way: let's
step through this function, watching CR2 to see just when it gets changed.
Dave The subroutine GetNoLoadResource at offset 0x0068 changes CR2 from false
to true. GetNoLoadResource is a wrapper to GetResource.
cam I restart the program and trace over the GetResource call.
Dave Yep, that's the function that trashes CR2.
cam Is it legal for the compiler to rely on CR2 being preserved across
Dave Yes. According to the PowerPC ABI (Application Binary Interface)
documentation -- section 3.6 in the first edition -- CR2 through CR5 are
nonvolatile and need to be saved across function calls.
cam Look at the code for GetResource. Since in System 7.5 GetResource is a
native trap with a routine descriptor, I can use the MacsBug dcmd drd to dump
that out. Here's what I get:
The RoutineDescriptor at: 011EDFEC
Mixed Mode Magic Trap: AAFE, version: 07,
routine descriptor flags: 00 (NotIndexable),
loadLocation: 00000000, reserved2: 00,
selectorInfo: 00 (No Selector),
routine count: 0000
--- Routine Record 00000000 -----
procInfo: 000002F0, reserved1: 00, ISAType: 01 (kPowerPCISA),
Routine Flags: 0004 (IsAbsolute, IsPrepared, NativeISA,
PassSelector, IsNotDefault), procPtr: 01219EEC,
storedOffset: 00000000, selector: 00000000
There's only one routine associated with the trap and it's the native
cam Where's that function? On the Power Mac, every ProcPtr is actually a data
structure that contains the routine's real address and TOC. This is called a
TVector (transition vector). This allows every fragment to have its own
globals, because the correct TOC gets loaded for each routine by the runtime
environment. So, to find the routine's address, you need to dereference the
Address 00E77B78 is in the "Porky WProcessor" heap at 00DFC430
The address is in a CFM fragment "Porky WProcessor" [non-write exec]
It is 00073058 bytes into this heap block:
Start Length Tag Mstr Ptr Lock Prg Type ID File Name
* 00E04B20 003D35D8+0C N
Apparently it's in the heap of the application.
cam So this program is patching GetResource. At least they have a native patch
-- a good habit these days because you don't know what traps will go native
from now on. If you're patching native PowerPC code with 680x0 code,
performance-sensitive code will run slower. For this reason, you should make
all of your patches fat. Let's disassemble the patch on GetResource.
Disassembling PowerPC code from 1219eec^
No procedure name
00E77B78 stwu SP,-0x0058(SP)
00E77B7C mflr r12
00E77B80 stw r12,0x0060(SP)
00E77B84 stmw r26,0x0040(SP)
00E77B88 stw r3,0x0070(SP)
00E77B8C sth r4,0x0074(SP)
00E77B90 extsh r4,r4
00E77B94 lis r5,0x4D42
00E77B98 ori r5,r5,0x4446
00E77B9C cmplw cr2,r3,r5
00E77C10 lmw r26,0x0040(SP)
00E77C14 lwz r12,0x0060(SP)
00E77C18 mtlr r12
00E77C1C addic SP,SP,0x0058
At 0x00E77B9C they do a compare and store the result in CR2. However, they
don't save and restore CR2 across this function, so it's trashed when we return
cam OK, I restart the program and manually save and restore the value of CR2
across the GetResource calls. I do this by futzing with bit 2 in CR2.
Dave Everything prints fine.
cam It looks like a compiler bug. Either they shouldn't be using CR2 or they
should be preserving it. In any case, the GetResource patch is trashing CR2,
and that changes a Boolean which causes us to read in extra data. The caller
never allocated enough space for the extra data, so the QuickDraw GX heap gets
Dave Holy cow! A compiler bug. Shouldn't we notify the compiler developer?
cam Well, this company has their own in-house development tools group. They
write their own compilers, linkers, and debuggers. We should contact them
anyway, so that they can create a patch that fixes this problem. [This patch,
"Office4.2x Update for Power Mac," is now available on most online services.]
Dave Why are they patching GetResource?
cam It looks like they were looking for resources of type 'MBDF' (menu bar
definition procedures). I can tell this from the instructions at addresses
0x00E77B94 through 0x00E77B9C. The PowerPC architecture has a limitation of 16
bits on the size of an immediate constant. So, if you wanted to compare a value
against a 32-bit constant, you would have to build the 32-bit value with two
instructions. This is what occurs at addresses 0x00E77B94 and 0x00E77B98, where
they insert 0x4D42 and 0x4446 together into a 32-bit value. If you look at the
ASCII of this constant, it's 'MBDF'. At address 0x00E77B9C, they compare this
constant to the resource type parameter passed to GetResource. Since that
parameter is the first parameter, it will be in register R3.
Dave Why didn't we crash when we had only one NFNT font installed?
cam This patch would cause ConstructNFNTDirectory to always overwrite the
buffer passed in. But that wouldn't always cause your machine to freak out. By
adding enough NFNT fonts, we trashed the QuickDraw GX heap significantly enough
to cause the crash.
Dave Wow, all this and it was an application patch that caused the problem!
It sure would have been cool if we could have used the patch dcmd.
cam Yeah. The patch dcmd does works on the Power Mac -- but we didn't know
that was the problem when we started.
Dave It's interesting that it was an application bug. That would explain why I
crash in a spreadsheet application by the same company. They share the same
DAVE HERSEY (AppleLink HERSEY) works in the QuickDraw GX PrintShop level 4
bio-containment facility, thousands of feet beneath the Cupertino R&D
campus. There, he develops PowerPC-native QuickDraw GX printing code, works on
Copland, and relaxes by dabbling with an occasional hot agent over lunch.*
CAMERON ESFAHANI (AppleLink DIRTY, Internet firstname.lastname@example.org) is the
shortest member of the Graphics team at Apple. To add a few more inches to his
height, he sometimes wears roller blades in meetings. If that doesn't help, he
has been known to don his large purple hat with sparkles.*
80-100 You could have a promising career writing compilers for a company up
45-70 Dr. MacsBug could always use another assistant.
25-40 Don't worry, it took us a while to figure it out too.
5-20 Visual Basic fan, are you?*
Thanks to Alex Beaman, Tom Dowdy, Ron Voss, KON (Konstantin Othmer), and BAL
(Bruce Leak) for reviewing this column.*