This article originally appeared in TidBITS on 1998-10-12 at 12:00 p.m.
The permanent URL for this article is:
Include images: Off

MacsBug for the Merely Geeky, Part Two

by Geoff Duncan

The first part of this article in TidBITS-449 looked at MacsBug, Apple's free low-level debugger, explained how to install and invoke it, and how to use MacsBug to recover from application crashes. It also discussed looking up system error numbers with MacsBug, plus converting between decimal and hexadecimal and doing basic math.


This time, we'll take a look at some MacsBug commands that reveal detailed information about your system and its applications. We'll also explain a bit about how your Macintosh and applications use memory, as well as how to make problem logs using MacsBug. MacsBug still isn't a friendly piece of software I'd recommend to all Macintosh users, but if you've come this far, going a little further won't hurt.

By Your Command -- Let's take a look at some common (yet useful) MacsBug commands. These and other commands are case insensitive; it doesn't matter if you capitalize them the way I've written them here. MacsBug also has a Help command that displays often-cryptic descriptions of these and other commands. Although you'll see many of MacsBug's capabilities have to do with obscure functions like traps, breakpoints, and disassembly, there are some useful gems to be found. Type Help Misc for a small sampling.

Thanks Heaps -- Each application running on your Mac stores windows, dialogs, documents, and other data in an area of RAM called its application heap. The size of a heap varies with the amount of memory allocated to an application. The system also has a heap, and it's the only one the Mac OS can resize on the fly. To change the size of an application heap, you must quit the program, change its memory settings in its Get Info window, then re-launch the program. This is one of the reasons proponents of other operating systems say the Mac OS has a weak memory model.

Heaps are divided into blocks, which can either be free (unused), relocatable (in use, but movable), or locked (in use and unmovable). Blocks in use can also be marked as purgeable, meaning that the application would prefer the data stay in RAM, but it can be released (purged) if the program needs more free memory. Each block of memory begins with a header containing some information about the memory block.

An application heap is a little like a disk in that it can become fragmented. As a program uses and releases memory (say, opening and closing documents), both free and occupied blocks of memory can become scattered throughout the heap. If the blocks are relocatable, the application re-organizes them to create larger areas of free space - just like optimizing a hard drive. If the blocks are locked, however, they can't be moved and the application may not be able to handle requests for large blocks of memory (say, to open a big document), even though there might be enough total free memory for the request.

Given this, you might wonder why programs ever use locked blocks. The reasons vary, but a good example is playing a movie. If the memory block containing a movie could be moved at any instant, the application would constantly have to check whether the memory had moved, which would destroy performance. By being able to guarantee the block won't move, the program can concentrate on playing the movie, then (in theory) give back the memory when its done. Some applications use more locked memory than others, but all applications use some.

Heaps can also become corrupted, usually when a program puts more data into a block than it was intended to hold. When this happens, it usually overwrites the header of the next block, and the Mac's Memory Manager loses track of that next block. The consequences can range from unnoticeable to disastrous, depending on the nature of that next block of memory.

If you'd like a program that graphically displays areas of an application's heap (and can peer into heap blocks), check out Joshua Golub's ZoneRanger, a 517K download from Metrowerks's Web site. It's a little unstable under recent versions of the Mac OS, but it's useful and educational.

< zoneranger.html>

MacsBug can tell you heaps about your heaps.

Logging Problems -- Because MacsBug is so good at uncovering information about your current application and the state of your Macintosh, it's useful for folks who are testing or evaluating software, as well as for software programmers. The only difficulty is determining what information is relevant when you're reporting a bug.

Fortunately, the folks who make MacsBug have made this easy for you. The StdLog command, as the name implies, creates a text file with a standardized log of information developers commonly need when they're investigating a bug. These logs are pretty big (usually about 20K), and contain the results of several MacsBug commands, including many discussed here. When you use the StdLog command, the log appears as a text file named StdLog on the desktop. If you use the StdLog command again, the information will be appended to any existing file named StdLog, rather than overwriting it.

Unless you're already in contact with the program's developer, I don't recommend sending a standard log via email as a bug report. Instead, describe the bug succinctly, and indicate you've made a MacsBug log of the problem, which you can send they like. Hang on to the file. Some developers will disagree with me, but, having handled my share of bug reports received via email, large reports with attachments are more awkward than concise notes. Frankly, if a program is in public testing, there should be few new bugs turning up. It's not particularly useful for a developer to receive dozens of log files about a problem that's already known and possibly already fixed.

Another Break Point -- In the next part of this article, we'll take a quick look at using MacsBug to restart machines automatically in the event of a crash. If you'd like more information about MacsBug, check out Apple's MacsBug Reference and Debugging Guide, available in Acrobat PDF format. Although it hasn't been updated since MacsBug 6.2 in 1991, this guide still offers detailed information on the inner workings of Macintosh memory management, plus traps, disassembly, and much more.

< MacsBug/Documentation/MacsBugRef_6.2.pdf>

In addition, the weekly journal MWJ published a lengthy two-part article earlier this year called MacsBug for Non-Programmers, which discusses several MacsBug features not covered here, including analyzing heaps and both displaying and searching memory. Both parts are reprinted on Ted Landau's MacFixIt site. If you can't get enough insightful Macintosh news, sign up for a free, no-obligation, three-week trial subscription to MWJ in time for their Mac OS 8.5 coverage, or download some free sample issues.