See if you can solve this puzzle in the form of a dialog between a
pseudo KON (Bo3b Johnson) and BAL (Martin-Gilles Lavoie). 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. And
you'll also learn interesting Macintosh trivia.
BAL Well, KON, I'm very disappointed to announce that I've fallen back to the level of a
newbie Mac programmer and am forced to ask you a question whose answer is probably
obvious. However, I'm stuck.
KON An easy one? Great, we'll have it fixed in no time -- and we'll give Puzzle Page
readers a chance to get a decent score for a change. Details, please.
BAL I'm working on a new version of our application plug-in. One of the dialogs we had
in the previous versions was very cluttered, and since we needed to add even more
stuff to it, we decided to use "tabs" to group related options. But now the system
crashes shortly after calling AppendDITL.
KON That's a well-traveled piece of the system. Why would you crash and no one else?
Let's check for reported bugs...just as I thought, Developer Technical Support has no
bugs listed for AppendDITL. Is the bug reproducible?
BAL 100% reproducible, and always after calling AppendDITL.
KON When is this AppendDITL call made?
BAL The plug-in code runs as part of the host application and monitors activity within
a floating window. One button in this floating window brings up a dialog containing a
list of items that can be edited with a second dialog that comes up. The second dialog has
tabs; when it's brought up, a call to AppendDITL is made to add the dialog items for the
first tab panel into this dialog.
KON How does it crash, exactly?
100 BAL A little while after AppendDITL exits, the dialog is visually messed up, and
the system drops into MacsBug with a bus error. Also, the application heap is usually
corrupted.
KON This is a code resource, right? Code resources can't have A5 globals, so any
globals would cause you to "color outside the lines." Are you using globals?
BAL The application plug-in interface file requires the use of globals, but it was built
with CodeWarrior, which uses register A4 as a code resource's globals pointer.
KON What if AppendDITL trashes A4 during execution? That would cause some of your
user item procedures to fail while trying to access globals.
90 BAL Well, let's check. When the dialog is first brought up and items are being
appended to it for the default tab, it immediately crashes. Here, witness the disaster...
KON Indeed, it crashes really hard. MacsBug is alive, but the system is barely alive; I
can't escape the application with es. Whoa! I can't even reboot withrb. Let's try that
again, and watch AppendDITL. We do an atb AppendDITL, then trace over the call.
Nope, A4 is untouched by AppendDITL. In addition, the heap was corrupted only after
several AppendDITL calls, so I'd say A4 is solid and not the problem.
BAL Time for the Vulcan Nerve Pinch?
KON Control-Command-Power? Indeed! While we're rebooting, can I see the code
where you add items to this dialog?
80 BAL My plug-in uses code that I've used in a standalone application. This code has
worked just fine since then, and I don't see why it should make a difference when used
in a code resource. It's pretty much by the book. When the user clicks the tabs in the
dialog, we make a DITL content switch using this code:
// At this point, clickedTab contains a DITL ID corresponding to
// the clicked tab DITL ID. 'kPanelBase' is the number of items
// in the base DITL (ID 29000).
if (gCurrentPanel != clickedTab) {
short numItems = CountDITL(theDialog);
if (numItems > kPanelBase)
ShortenDITL(theDialog, numItems - kPanelBase);
Handle ditlResource = GetResource('DITL', clickedTab);
AppendDITL(theDialog, ditlResource, overlayDITL);
ReleaseResource(ditlResource);
gCurrentPanel = clickedTab;
}
The first time around, the ShortenDITL routine isn't called because numItems is equal
to (but not greater than) kPanelBase. I verified this at run time with source-level
debuggers.
KON I'm wondering about the ReleaseResource right after the AppendDITL call.
70 BAL Inside Macintosh recommends doing this to avoid using altered DITL resources
if we later display a dialog whose item list was previously altered. After the crash, I
examined the content of the application heap to see if any expected resources were
missing. I used hd r to dump all resource information in the current heap; I made
sure that all my resources were loaded and that my code isn't inadvertently using the
host application's resources.
KON Well, we know Inside Macintosh isn't always right, so let's display the
DialogRecord.items handle after AppendDITL. We'll find this handle with thePortand
then dm . dialogrecord.
BAL The size of the handle is different after the call, and it appears to make a copy of
the DITL into this handle, so calling ReleaseResource shouldn't be a problem.
KON Did someone patch AppendDITL? Or perhaps the dialog underneath is causing a
conflict?
65 BAL Let's look at AppendDITL with the debugger. Do an il AppendDITL. Hmm, the
code is still in ROM at CommToolboxDispatch, so it's not patched. You also wouldn't
expect any conflict between the two dialogs on the screen, because you have to pass the
DialogPtr to AppendDITL, which gives it the exact DialogRecord.
KON OK, so far my ideas aren't panning out. But I notice that although it always
crashes, it doesn't seem to crash the same way every time: sometimes it takes two
AppendDITL calls and sometimes one.
BAL What could make it do that?
KON It's probably using some nearly random chunk of memory. Let's make it more
reliable in the way it crashes by turning on heap scramble with hs. Do you want to use
QC orβ Jasik's debugger instead? They're an even stronger way to make it more
repeatable.
BAL No, this still seems like an easy bug, so let's stick with MacsBug. Thaths seems to
help.
KON As near as I can tell, there's some problem with the fonts. Most of the crashes
happen while it's drawing text. It nearly always crashes in a TextBox or TESetText
call, during the handling of DrawDialog. Do you change the fonts used to draw the
dialog?
60 BAL I do. Here's the code:
((GrafPtr) theDialog)->txFont = Geneva;
((GrafPtr) theDialog)->txSize = 9;
if (*(((DialogRecord*) theDialog)->textH)) {
// This will have to come from a resource for localization.
(*(((DialogRecord*) theDialog)->textH))->txFont = Geneva;
(*(((DialogRecord*) theDialog)->textH))->txSize = 9;
(*(((DialogRecord*) theDialog)->textH))->lineHeight = 12;
(*(((DialogRecord*) theDialog)->textH))->fontAscent = 10;
}
What exactly happens in AppendDITL when it adds text items (either static or editable)
to a dialog whose port's font and size were altered?
KON Beats me. Intriguing question, though. Since it's only display code, let's comment
it out.
55 BAL It still crashes.
KON Well, then it must not matter if we change the fonts in the window. By the way,
BAL, while I don't think this is the solution to the bug, you should at least use the
regular calls like TextFont and TextFace instead of setting the fields directly, and make
TextEdit calls for the parts that modify the TEHandle.
BAL Oh. Right.
KON Time to look at a stack crawl? Let's try sc.
50 BAL It says:
Start of link chain does not point to a stack frame
KON Bummer. OK, how about doing an sc7, even though it's not as reliable? It won't
miss anything, but it will show up a lot of junk addresses that aren't real. When you're
desperate for information, you turn to sc7.
BAL Geez, KON, could we make it any smaller for our developreaders?
KON Hey, it's not critical for them to see the details. And our lawyers insisted on a full
disclosure of all information related to finding the bug. Readers can always get out
their magnifying glasses, if they want to.
BAL Good thing it's high resolution or they'd have to call the psychic hotline instead of
just squint. Hey, have you ever used one of those magnifiers on ants?
KON BAL, can we focus on the problem at hand? Let's do the normal thing and skip all
the unnamed routines, and just try to get a feel for what was going on. The routines
that have a frame address in the second column are more likely to be valid calls; we
can probably ignore the others.
45 BAL Well, there's a call to MyWindowEvent+00294, and one to
MyDoStyleList+00044, both my routines. Further down are my
DoStyleListDialog+003F0 and MyDoStyleEditor+00080. Among the Toolbox calls of
interest, there's one to _NewDialog+001C4, and later to _DrawDialog+0000A, and
maybe in response to that a call to _TextWidth+00048.
KON The TextWidth call makes me think the Font Manager might be damaged.
BAL Further down, without any frame addresses, we get six KillPicture calls, two
sIntRemove calls, two Jackson calls, and some other stuff that implies the computer
ran off through the weeds for a while before it finally died. Hmm...there's no call to
AppendDITL in the chain, though, and sc7 wouldn't miss it.
KON I thought you said it crashed in AppendDITL?
35 BAL No; to be precise, I said it crashes shortly after AppendDITL, and if I comment
out the AppendDITL call, the crash no longer happens, so it must be related.
KON OK, but I still think the Font Manager is trashed, because when I look in low
memory at CurFMSize, I see the font size is 4583! That's a bit big for this computer.
30BAL Not only do fonts get smashed, but sometimes the dialog's added items will draw
with wacky colors. It appears that the whole graphics port (the current window) gets
written over sometime during the AppendDITL call.
KON Hey, there's Dave Polaschek and Quinn. Dave's run into problems with
AppendDITL before, so let's ask him about it. Dave, what exactly does AppendDITL do?
DAVE Nothing too tricky: It locks the new DITL handle and then steps through the items
in the list, loading and installing each one into the dialog. It uses GetNewControl for
controls, copies in the static text items, and loads and puts the handles to PICT
resources in the DITL. When it's done, the new DITL handle is unlocked but left in
memory. There's an old version of the source code in Technote PR 09, "Print Dialogs:
Adding Items."
KON Any nasty behavior or bugs that you know about?
DAVE The only common problem I've heard of is with 'ictb' resources. Are you using
them to specify fonts and sizes or color tables for your DITLs?
25 BAL No. Also, no font-specific action is taken at run time -- I don't call the Font
Manager, and I don't directly call ATM. The only thing related to fonts that I can see is
that the dialog's font and size are changed to Geneva 9 before the AppendDITL (which
goes against guidelines for localization). Wait, there's also a font pop-up menu that's
being updated with the current font list when the dialog gets called up. But both these
things worked before I started playing with AppendDITL.
KON Still, those 'ictb' resources sound suspiciously like what we're seeing. Quinn,
have you heard of any bugs relating to 'ictb' resources?
QUINN Nothing specific, just what Dave said: they're more trouble than they're worth.
Have you looked for 'ictb' resources in the heap? Try doing an hd ictb.
KON Hey, there are a bunch in there! How about in the resource fork? I'm doing an rd
ictb too.
20 QUINN Sure enough, there are some in the resource fork. Those 'ictb' resources are
only used to change the look of the dialogs; they aren't required. Since we don't trust
those things, why don't you delete them in a copy of the plug-in? Where's ResEdit?
KON OK, I cleared them out; now let's try it again. Dang! It still crashes, and the same
way. I would have bet that was it. How many points do I have left?
QUINN Not enough to clear your karma point deficit. Why don't you do an atb
DrawDialog, and then just an so that we can see what happens before it dies. We
won't see any PowerPC calls, but this is all 68K code anyway.
KON OK. The last dialog-related thing it did was call TETextBox to draw one of the static
text items -- another hint that it's a font problem.
DAVE To find this, you'll need to reduce the number of variables. See if having fewer
items in your dialog changes anything. Maybe a corrupted item or a resource conflict
is causing the problem. You said you're using at least one pop-up menu, right? Is its
menuHandle properly loaded?
15 BAL I tried a number of variations on what you've suggested; I simplified the code
in all these ways:
None of this worked. In all cases, the same bad behavior occurs after I come out of
AppendDITL. I even tried using just a single plain button and one static text item, but it
still trashed the heap. Furthermore, all the pop-up menus in this dialog (and its tab
panels) use different menus, and all menus are loaded and installed during startup,
with InstallMenu(theMenuHandle, -1).
KON Well, this is getting even more interesting now. I'm willing to bet that this is a
bug in AppendDITL, but I can't put my finger on it just yet. To simplify even further,
let's make a small test application with only the code that handles the dialog.
DAVE Good idea. But I'm hungry, so I'll leave you to it. Anybody want to have dinner?
QUINN I'll join you -- though I like the taste of freshly killed bug better.
KON That leaves it to us, BAL. We're making strong progress now, though, so we should
have this one crushed in an hour or two.
BAL KON, we've been looking at this for over five hours now, we're nearly down to 10
points, and we still can't find it.
KON I'm just going to make a simple application that creates the dialog using your code.
And I'll copy the resource fork of your plug-in so that we get all the DITLs. I want to
rule out the host application having any effect.
10 BAL OK, excellent! And it still crashes with the test app. Now we can keep
simplifying until we find the offending code.
KON Let's take a big simplifying jump and change the dialog to just a control and a
static text in each tab panel, as in your test.
BAL Huh! It still crashes in this nearly trivial case. I guess we can't blame the host
application.
KON Now let's keep trying to find where it stops crashing. I've removed the entire
content of the tab panels' DITLs and replaced their content with a single plain button
straight out of ResEdit's tool palette.
Each button on each tab panel says something different, just to make sure they're
actually removed when they're tabbed out.
BAL Look at that, it worked! I doubt we have a limit of one item per AppendDITL --
that would be ridiculous.
KON I agree. So it must have something to do with static text. Fonts, I tell you! Fonts,
fonts, fonts, fonts, fonts!
BAL Easy, KON. We'll find it. Let's put the static text items back to make it crash again.
KON OK, now let's trim the icons and other junk out of the resource fork, to be sure
it's not interfering, and to make it as simple as we can get yet still crash.
5 BAL Hey, there are 'ictb' resources in our test app!
KON They must have come from the plug-in when we copied the resource fork.
BAL And look at this. My plug-in file has grown in size between its installation and its
first run in the host application. I don't modify my own code in this plug-in --
something's fishy.
KON You said you weren't using any 'ictb' resources, yet earlier we saw lots of them in
your plug-in.
BAL Just a second, while I call the host application's manufacturer... Ahem. Get this:
They warn me to make sure to have an 'ictb' resource for every 'DITL' resource in a
plug-in file. If any are missing, the host application adds empty 'ictb' resources for
what it thinks are "deficient" plug-in files. I'm very curious about why the host
application requires the presence of 'ictb' resources in plug-ins.
KON D'oh! The host application is modifying your resource fork? That explains why
our 'ictb'-deleting experiment didn't work. Sure enough, if I delete the 'ictb' resources
from the test app, it works fine.
BAL Obviously the host application doesn't know I'll be using some of those DITLs to
expand another DITL. The Dialog Manager ends up having too few 'ictb' entries for the
number of items in the expanded dialog, and when it gets to the end of the 'ictb'
resource that the host application created, it starts reading garbage from memory,
trying to set fonts, sizes, and colors.
KON The Dialog Manager sets up the 'dctb' and 'ictb' data structures only when the
dialog is created, and doesn't change them for AppendDITL? That does it, I'm filing a
bug against AppendDITL. Let's see, that's #1377732.
BAL The static text items are a bit more fragile in this case, which is what we found
with that test of having one static text item. Buttons just have a ControlRecord -- and
a color table, which only causes funny colors to appear if the Dialog Manager is using
random bytes out of memory.
KON Of course! For static or editable text items, it blindly goes off the end of the
handle, using whatever junk is in memory as a txFont, txFace, txSize, or color table.
When it set the font to number 43003, the size to 15433, and so on, the Font Manager
was none too pleased.
BAL I added an empty 400-byte 'ictb' resource to my project, with the ID of the base
dialog. This is enough to accommodate this dialog's items, plus any items I add through
AppendDITL. Everything works fine now.
KON Hot dog! I knew we were going to crush this thing before too long. You have no idea
how glad I am that this one has been killed. Well, actually, I bet you do; it stumped us
for seven pages.
BAL The host application's manufacturer also told me they need to add 'ictb' resources
in order to solve an old problem where plug-ins used dialog windows with the same IDs
as some of their application's dialog windows. When these dialog windows were loaded
by the system, the system would look for its associated 'ictb' resource with
GetResource, which looks through the resource chain until it finds one. Sometimes it
would pick an 'ictb' in their application, which wasn't suitable for the plug-in's dialog
window, causing the same kind of problems we've experienced with my plug-in. Watch
me never assume what's in my resource fork from now on!
KON Nasty.
BAL Yeah.
SCORING
| 70-100 | How would you like to work in Apple DTS? Today? |
| 45-65 | How about a contract as a Webmaster? |
| 25-40 | We hear that the Highway Department is hiring. |
| 5-20 | Don't give up your day job.* |
MARTIN-GILLES LAVOIE (mouser@zercom.net) constantly looks for more efficient
means of using his hands. After experimenting with branch-prediction-enhanced,
tristate-binary-enhanced, and floating-point-enhanced finger-coded binary
techniques (pioneered by Tobias Engler in develop Issue 21), he went on to make a
medieval ring mail consisting of over 26,000 rings. He hopes to make adequate use of
his hands on his vacation in France, where he'll be touring medieval festivals and
castles. Then he'll be back in MontrÉal-based Globimage, Inc., where he works on
prepress-related utilities and automation software.*
BO3B JOHNSON (bo3b@apple.com), whose name is pronounced "Bob," has been
programming the Macintosh seemingly forever and still hasn't lost interest (though it
was touch-and-go there for a while). Having recently returned to Apple's Developer
Technical Support group after a long stint as a dedicated slacker, windsurfer, and
pursuer of arcane knowledge, Bo3b is rediscovering the joys of working for a living
(and has actually found a few). Getting up in the morning, however, remains a serious
challenge.*
Thanks to Dave Polaschek, Quinn "The Eskimo!", KON (Konstantin Othmer), and BAL
(Bruce Leak) for reviewing this column.*