Kon & Bal'S Puzzle Page

AppendDITL Apoplexy

Martin-Gilles Lavoie and Bo3b Johnson

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 with rb. 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 thePort and 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. That hs 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 develop readers?

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?

QUINNNothing 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.

20QUINN 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:

• I disabled any filter procedures passed to ModalDialog.
• I removed any user item procedures.
• I removed any code-handling items in tab panels.
• I converted (one by one) all items in the first tab panel to static text items, relaunching the host application every time.
• I reduced the number of items in the first tab panel, down to six static text items.
• I removed any code having to do with the dialog's base elements (those that stay regardless of the current tab).
• I converted the base dialog's elements to static text.
• I moved items around so that appended items wouldn't be surrounded by PICTs that form the frame of the tab area.

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

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.*