Here's a fun game: let's plot Macintosh software on a map of the Earth, based on how Mac-like the software is. We would naturally plot the points representing the easiest, most intuitive software for the Mac OS at Apple headquarters in Cupertino, CaliforniaShow full article

Hide full article

Here's a fun game: let's plot Macintosh software on a map of the Earth, based on how Mac-like the software is.

We would naturally plot the points representing the easiest, most intuitive software for the Mac OS at Apple headquarters in Cupertino, California. As we plotted more points, we'd find the surrounding San Francisco area would be peppered with thousands of dots, each representing a Macintosh program. In fact, most Macintosh software - even hard-to-learn programs or obtuse, cryptic utilities meant for power users - could be plotted within, say, a few thousand miles of Cupertino. That's not the kind of travel you'd undertake without packing a toothbrush and some clean underwear, but, for many people, getting there is at least conceivable in today's world.

However, on the opposite side of the globe, well south of Mauritius in the Indian Ocean, we would find a dot representing MacsBug.

MacsBug is Apple's low-level assembly language Macintosh debugger. If I remember correctly, MacsBug stands for "Motorola Advanced Computer System Debugger" and predates the Macintosh, first appearing in 1981. There's nothing Mac-like about MacsBug: it has no menu bar, no menus, no windows, no icons, no dialogs, and no buttons. Its display is a jumble of numbers, letters, and some cryptic words. You communicate with MacsBug using a command line, precisely the thing many people sought to escape with the Mac. MacsBug doesn't provide intuitive feedback about practically anything - in short, MacsBug violates every aspect of the Macintosh ideal.

MacsBug breaks these rules because it was designed to live underneath the Macintosh system software so programmers can see what's going on in overwhelming detail. MacsBug provides direct access to things users were never meant to see: system globals, application heap zones, CPU registers, task queues, and executing code.

Sounds scary, right? It is. But MacsBug is powerful, and power is seductive. Mastering MacsBug would require most Macintosh users to apply for passports and visas, receive immunizations and inoculations, make expensive travel arrangements, endure radical culture shock, leave their real lives, and maybe even grow gills. However, you can benefit from MacsBug without travelling to the other side of the world (or learning to read assembly language). MacsBug's not for everybody, but if you've been willing to travel from Cupertino to, say, Ohio, for another Macintosh program (like DeBabelizer or ResEdit), you should be able to put MacsBug to work for you. MacsBug can provide detailed information about your computer and problems you might be having, and - perhaps most significantly - save work in other applications when an otherwise fatal system error occurs.

Installing MacsBug -- You can download MacsBug for free from Apple. I recommend the most recent version available - even if it's not a final release - because it's likely to work with the latest versions of the Mac OS. You can also download a PDF version of Apple's pre-PowerPC MacsBug documentation, which makes for interesting reading if you're curious about MacsBug's more abstruse capabilities. As of this writing, the current version of MacsBug is 6.5.4.a6.

<http://developer.apple.com/dev/tools/debuggers/ MacsBug/>

You install MacsBug by dragging it into your System Folder and restarting your Mac (feel free to ignore other files that come with it). Your Mac OS startup screen will say "Debugger installed" to let you know MacsBug is there. MacsBug works with any Mac newer than the Mac Plus and System 6.0 or higher; it might even work with earlier system software. Although for years MacsBug occupied only a few hundred kilobytes of RAM, changes to the Macintosh architecture over the last few years mean MacsBug commonly requires 1 to 1.5 MB of RAM on modern Macs.

Recent versions of MacsBug come with a program called MacsBugApp, which, despite limitations, is a stand-alone application that behaves much like MacsBug itself. It's occasionally flaky, but you can use it to follow along with some of the examples below without installing MacsBug itself.

Invoking MacsBug -- Once you've installed MacsBug, you might wonder where it is - nothing on your screen changes. There are two ways to enter MacsBug: deliberately and dramatically.

To enter MacsBug deliberately, press Command-Power, where Power is the key you use to turn on your Mac from the keyboard. This combination works on most Macs; older Macintosh models (up to the NuBus Power Macs, I believe) may also have a physical interrupt switch on the front, side, or back of the machine. If you've ever pressed a switch and seen a mysterious dialog containing only a greater-than symbol (">"), that's the interrupt switch. (By the way, that dialog is referred to as MicroBug or the programmer's window; to get out, your best bet is to type the letter G and press Return. You'll never see MicroBug with MacsBug installed, but Apple has a brief TechNote about it if you're curious.)

<http://developer.apple.com/technotes/tn/ tn1136.html>

You can also invoke MacsBug by holding down the Control key when your Mac starts up. Only programmers typically need to do this, but I was once surprised by an old keyboard with sticky modifier keys.

The dramatic way to enter MacsBug is to experience a system error. Normally, a system error produces a bomb dialog, or a program quits, resulting in a dialog saying "An error of type -1 occurred." or something equally unhelpful. Now, MacsBug instantaneously appears, completely taking over your startup monitor. You need to be careful about how you exit MacsBug in response to a system error; your options are covered below.

First, let's describe MacsBug's display - it's divided into four areas. At the bottom is the command line, where you type MacsBug commands. Immediately above the command line is the PC region: PC stands for "program counter," and it displays the next instruction the CPU will execute, along with the disassembly of that instruction. This information is for programmers: it can give you an idea of where a system error occurred, but things like instruction pipelining (where the CPU executes more than one instruction at a time) sometimes mean the PC may not point to the actual error. Programmers sometimes need to disassemble forward and backward from the current PC to find the problem.

The largest area of the MacsBug display is called the output region, and it's where MacsBug shows the results of your commands. Although it doesn't have scrollbars, the Page Up, Page Down, Home, and End keys do scroll the output region's history. When you first enter MacsBug, it displays the version and copyright information in the output region, along with the reason MacsBug was entered.

Finally, along the entire left side of the MacsBug display is the status region, most of which displays CPU registers (R0 to R31 for PowerPC code, D0 to D7 and A0 to A7 for 68K code), along with the current stack pointer and, for 68K code, the stack itself. Don't worry about the stack and CPU registers. In the middle of all this, however, is some important information: beneath the label CurAppName, MacsBug shows the name of the currently executing application. If you entered MacsBug because of a system error, this is the program that had control when the error occurred, although it may not be the program you were using. Programs continue to execute when they aren't frontmost, and many things we think of as extensions - like Web Sharing and File Sharing - are in fact faceless applications that run in the background. Further, although CurAppName always says what program was in control when a problem occurred, the real problem could be in an extension, driver, or other software that underlies an application.

Near CurAppName, MacsBug also displays VM if you're using virtual memory, vM to indicate MacsBug was invoked while the Memory Manager was swapping between real and virtual memory, or RM to show you're using real memory. MacsBug also shows a number from 0 to 7 that indicates the interrupt level before MacsBug was invoked. Interrupts tell your CPU to set aside whatever it's doing and immediately take up a more important operation - they're used to handle mouse actions, screen redraws, network activity, serial port operations, and many other functions. MacsBug itself takes control of your system by generating a level 7 interrupt, otherwise known as a Non-Maskable Interrupt or NMI. (If you enter MacsBug deliberately, it tells you that the reason is an NMI rather than a system error.) An NMI overrides everything and can't be interrupted by other tasks. Generally, this isn't a problem: your applications aren't even aware they've been suspended. However, other computers on a network can notice that your Mac is no longer responding. After a few minutes, AppleShare servers will assume your Mac is gone and drop their connections; similarly, Internet servers might drop connections, and ISPs might hang up on you.

Stop This Crazy Thing! Now that you're in MacsBug, the first thing most sensible people want to do is get out. If you invoked MacsBug deliberately, this is simple: just type G then press Return, or press Command-G. This stands for Go, and tells your Mac to resume operating right where it left off. MacsBug then vanishes, your Mac's normal display reappears, and your Macintosh universe resumes its normal, harmonious state.

If you entered MacsBug as the result of a system error, try the following options. First, under CurAppName in the status region, note the name of the program executing when the error occurred. Also look at the bottom of the output region for the reason MacsBug was triggered. It might say something like "bus error" or "illegal instruction." If you need to see what you were doing on screen when the error occurred, pressing Escape toggles between your normal Macintosh display and MacsBug. Don't become confused: pressing Escape doesn't exit MacsBug, it just shows your screen at the instant MacsBug was triggered, which can be handy for writing down that paragraph of erudition that you otherwise stand no chance of recreating. Press Escape again to return to MacsBug.

• Next, try typing G then pressing Return, or pressing Command-G. Most likely, you'll immediately reenter MacsBug with the same error, but it's worth a shot.

• Type ES then press Return. ES stands for Exit to Shell, and tells MacsBug to terminate the current application and return you to the Finder. This is roughly equivalent to forcing an application to quit by pressing Command-Option-Escape. You may have to try ES a few times - just make sure you check which program is currently executing before repeating the command. If ES returns you to the Finder, save all your work and restart. If an application appears to have locked up, you can enter MacsBug intentionally and use ES to terminate that program. Use this capability with discretion, however: there's no telling what might be left in your computer's memory, whether any files that program had open will be closed properly, whether preferences might be damaged, etc. If you do this, restart as soon as possible.

• If none of these techniques work - you keep popping into MacsBug with a system error - you may have no choice but to restart, even though it means losing unsaved work. You do this by typing RB (for ReBoot), then pressing Return. The RB command unmounts your startup volume and then restarts the machine. If you have multiple volumes, this action can result in delays the next time you need to use those disks: since they weren't properly unmounted, the Mac makes sure they're okay before mounting them on the desktop. You can alternatively use the RS command (for ReStart) to unmount all drives, then restart the system. Some programmers may tell you the RS command is dangerous, since it could write corrupted volume information back to your drives, potentially leading to data loss or a session with a disk recovery tool. In my experience, everyday problems with the RS command are quite rare, and changes to both the RS and RB commands in recent versions of MacsBug reduce the danger further. However, either command is preferable to turning your computer off and on.

Note that there are crashes from which MacsBug can't save you, and there are crashes that will still freeze your Mac, failing to invoke MacsBug at all. (The latter are often caused by poor or non-existent error checking when a program is low on memory.) In these cases, MacsBug can't help you, but having it installed doesn't hurt.

Impress Your Friends -- Now that you can get into and out of MacsBug, let's look at some simple tricks to enhance your guru status.

Being a low-level programmer's tool, MacsBug's default numbering system is base 16, or hexadecimal. Hexadecimal digits run from zero to fifteen, with ten through fifteen represented by the letters A through F. So, the number 200 is written as C8 in hexadecimal, which means "twelve times sixteen, plus eight." Hexadecimal is useful for representing binary values, and if you've done much HTML authoring, you've seen six-digit hexadecimal values like 3366CC used to specify colors. This might be wonderful from MacsBug's point of view, but hexadecimal isn't intuitive for people like me who have trouble making change for a dollar. Fortunately, you can tell MacsBug a number is a normal decimal number by preceding it with a pound symbol ("#"). Thus, if you type 42, MacsBug sees it as hexadecimal and thinks you mean 66 (four times sixteen, plus two), but if you type #42, MacsBug thinks you mean 42.

One instance where this esoteric knowledge becomes practical is in conjunction with MacsBug's error command, which returns a short description of cryptic Mac OS error numbers. If a program complains that "an error -43 occurred" you can identify the error number by popping into MacsBug, typing "error #-43", and pressing Return:

 $FFD5     #-43  fnfErr - File not found

The application is telling you it tried to open a file, but couldn't find it. Depending on the program, this might be caused by a missing extension, plug-in, or document, but at least it gives you something to go by. The error command can score big points: I once got a frantic call from a small business owner who had an AppleScript that essentially looked up records in a database and printed a variety of labels. "I think it has corrupted the hard drive! Every time I need to use the machine, it says there's an error -1711 - big error numbers are really bad, right?" So, assuring the caller that the number of digits in an error has nothing to do with its severity, I popped into MacsBug and looked up the number:

 $F951   #-1711  errAEWaitCanceled - in AESend, the user cancelled
   out of wait loop for reply or receipt

It turned out this script had been designed to run overnight, since it spent most of its time waiting around for other applications. However, the script was instead being run during lunch breaks and other odd times. Whenever someone needed to use the machine, they pressed Command-Period to stop the script, which promptly produced this error. The situation was harmless, but in this case having MacsBug installed helped me reduce my caller's blood pressure and gave me a low-stress consulting job fixing the script.

You can also use MacsBug to convert between decimal and hexadecimal, which can be useful with other MacsBug commands. Since MacsBug assumes numbers are hexadecimal; entering "3366CC" on MacsBug's command line yields this result:

 3366cc = $003366CC   #3368652   #3368652   '*3fA' (between #3M and #4M)

This shows the number 3366CC as a hexadecimal value, an unsigned decimal value, a signed decimal value, an ASCII value, and (often) a semi-human-friendly conversion to memory units, in this case between three and four megabytes. If you're converting from hexadecimal to decimal, the number you want is the third - the signed ASCII value (notice that it's preceded with a pound sign). Thus, 3366CC in hexadecimal is equal to 3,368,652 in decimal. The second (unsigned) decimal value will be identical for non-negative numbers, but wildly different for negative numbers. Convert #-43 and see what you get. You can use this trick to convert numbers up to about 2.1 billion.

Recent versions of MacsBug include basic mouse support in the output region, enabling you to click on a word, number, or term in order to place it in the command line. Although this mouse support drives some programmers insane (say, if the mouse moves while debugging a problem with a pop-up menu), you can quickly convert a number from hexadecimal to decimal by clicking it and pressing Return.

Finally, you can do math using MacsBug - try entering 32 + 32, or #32 + #32. Programmers occasionally rave about this capability, since they often need to play with hexadecimal values after an application has crashed. But most people should stick to the Calculator desk accessory.

Break Point -- In the next part of this article, we'll look at some MacsBug commands that provide important information about your computer and applications, and how to make MacsBug automatically restart your computer if an application crashes, which can be great for unattended servers.

Hide full article

SYNC YOUR PHONE with The Missing Sync: Sync your calendar,
address book, music, photos and much more between your phone
and Mac. Supports ANDROID, BLACKBERRY, PALM PRE and many
other phones. <http://www.markspace.com/bits>

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 crashesShow full article

Hide full article

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.

<http://db.tidbits.com/article/05118>

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.

• How - Displays the reason MacsBug was invoked. If you entered MacsBug deliberately, this command tells you the cause is an NMI (Non-Maskable Interrupt).

• Stat - Displays the current date and time (along with how long since you last restarted the machine), the name of the current application, and some technical information about your system. Stat is handy for figuring out how long it's been since you last restarted your machine - for instance, although it's asleep much of the day, my PowerBook has been running for more than four months.

• ProcInfo - Displays a summary of running applications (or processes), including faceless background programs. The status column indicates which program is in the foreground (this might be different from the currently executing program found under CurAppName), which applications are in the background, and which are background-only. You can also see the programs' type and creator codes, along with how much memory they take and how much of that memory is free. These memory numbers are in hexadecimal: if you're using a recent version of MacsBug, remember you can just click them and press Return to translate the numbers to decimal. This is a great way to find out how much memory is used by the Finder and background applications like File Sharing, Web Sharing, or Desktop PrintMonitor. Note that the total memory size listed here does not include any temporary memory in the system heap the application might be using; for instance, MacsBug might say Internet Explorer is using 5 MB of memory, while About This Computer under Mac OS 8.x could report a significantly higher number since it includes temporary memory with its totals.

• File - Did you know that the Mac OS can open only 348 file forks - data and resource - at the same time? The File command displays a complete list of open file forks, sometimes including both the data fork and resource fork of the same file. In this list, you'll see not only any documents or files you currently have open, but all your running applications, fonts, disk directories, extensions, plug-ins and shared libraries used by applications, and more. At the end of the list, you'll see how many of the file forks are currently open: don't be surprised if this number approaches 200. It's not unusual for designers, production artists, programmers, and Web developers to open too many files inadvertently. Usually, quitting an application (or removing unused fonts) solves the problem. If you want to see which files a particular application has open, use the command File -P, followed by the process serial number of the program you're curious about. Process serial numbers are four digits long, and listed in the first column of the ProcInfo command, above. To see all open files except for fonts, type File 0 (that's a zero, not the letter O).

• Vol - Displays information about all mounted disks. For the most part, you already know what disks are mounted on your desktop, but this command tells you a little more about them. First, it provides (in hexadecimal) separate totals for the number of files and folders on a drive, unlike the Finder's Get Info command which just displays the total number of items. (It also tells you the allocation block size for a volume, but these numbers seem to be incorrect for HFS+ disks.)

• StopAS - Shuts down connections to all AppleShare servers, whether you connected to them using AppleTalk or TCP/IP. (Earlier versions of MacsBug support the StopXPP command, which just closes AppleTalk connections.) For non-programmers, StopAS has two uses. First, you might want to shut down all AppleShare connections if a server is giving you trouble (like disk errors or slow response due to network congestion). Second, remember from the first part of this article that AppleShare servers give up on you if you spend more than a couple minutes inside MacsBug. There's another downside: if this happens, when you exit MacsBug your applications will spend a couple more minutes in limbo wondering where these servers went. Using StopAS to shut down AppleShare connections eliminates delays when you come out of MacsBug.

• DX - When programmers are debugging an application, they often insert commands called "user breaks" that deliberately trigger MacsBug. User breaks are helpful if a programmer needs to see what's going on before a program crashes rather than after it has taken leave of the known universe. Programs released to the public don't usually have user breaks, but sometimes they slip through: I have a script that commonly triggers a few in Eudora Pro, and I've seen plenty in pre-release and beta software. If you don't have MacsBug installed and encounter a user break, the application is likely to crash with an error -10; with MacsBug installed, MacsBug will take over your system just like a system error, but will show the cause as a user break along with (sometimes) a message from the programmer. You can often just press Command-G to get out of a user break, but you should report the user break to the developer as a bug. However, if you hit an annoying one and you're trying to get work done, you can use the DX command to tell MacsBug to ignore user breaks: DX OFF turns user breaks off, DX ON turns user breaks on, and DX NOW tells you whether user breaks are enabled or disabled without changing their status. If you turn user breaks off, MacsBug turns them back on again when you restart your machine.

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.

<http://www.metrowerks.com/tools/software/ zoneranger.html>

MacsBug can tell you heaps about your heaps.

• HT - The HT (heap total) command displays information about the current application's heap, including the amounts of free, relocatable, locked, and purgeable memory. HT provides results in hexadecimal and decimal numbers, expressed in bytes: you can use this command to see a bit of what's happening behind the scenes. If a program reports it's running low on memory but the HT command shows a large amount of free RAM is available, then the heap is probably seriously fragmented. You can try quitting and relaunching the application. If the problem persists, however, allocating more memory to the program may not solve the problem, since large areas of memory can be fragmented just as easily as smaller ones. (Of course, if a program complains it doesn't have enough memory and HT shows there truly isn't much memory available, then increasing the application's memory allocation should help.)

• HZ and HX - The heap total command, HT, works only on the current heap. How do you get information on a heap belonging to a different application? First, you need information about the other heaps, available via the HZ (heap zones) command. HZ lists all the heaps, complete with the names of the applications to which they belong. Each item on HZ's listing begins with a decimal number, starting with #1. You can use these numbers with the HX (heap exchange) command to switch to a particular heap. So, if HZ indicated Nisus Writer's heap was #9 on my machine, I could type HX #9 to switch to Nisus Writer's heap regardless of which application was running when MacsBug was invoked. Once I'd done that, the HT command would show me information about Nisus Writer's heap.

• HC - The HC (heap check) command tells MacsBug to check if the current application heap is corrupted; you can use HC ALL to check all heaps at once. You might try this if an application is behaving oddly but not crashing. If the HC command reports a heap is corrupted, things may get worse quickly: save all your work and quit the application. Note that this command can be fooled into thinking a heap is corrupted if MacsBug is invoked while an application is shuffling blocks around using the Memory Manager. There are ways you can tell MacsBug to keep running until a safe moment, but it's usually simpler to leave MacsBug using G (or Command-G), wait a second, then re-enter MacsBug to see if the problem persists. If you're curious, look up the WNE and WNEPPC (only available in recent versions of MacsBug) commands in MacsBug's help.

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.

<http://developer.apple.com/dev/tools/debuggers/ 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.

<http://www.macfixit.com/reports/MacsBug.shtml>
<http://www.gcsf.com/pages/mwj/>

Hide full article

StuffIt Deluxe 2011 has everything you need to backup, encrypt,
share, and compress all of your photos, audio and documents.
Compress it. Secure it. Send it. Try StuffIt Deluxe 2011 today!
Click here for a free 30-day trial: <http://stuffIt.com/tidbits/>

Previous parts of this article explored MacsBug, Apple's free low-level debugger. First, we covered installing MacsBug and using it to recover from application crashes - we also established MacsBug as possibly the least friendly software you'll ever encounter on a MacintoshShow full article

Hide full article

Previous parts of this article explored MacsBug, Apple's free low-level debugger. First, we covered installing MacsBug and using it to recover from application crashes - we also established MacsBug as possibly the least friendly software you'll ever encounter on a Macintosh. Next, we discussed common MacsBug commands that reveal detailed information about your Mac, applications, and memory, and how to make logs of problems you encounter. Although MacsBug isn't for the faint of heart, it can be useful even for people who don't program for a living.

<http://db.tidbits.com/series/1057>

Now that you're familiar with MacsBug, you can put your knowledge to good use for automatically restarting crashed servers.

Poor Man's Server Restart -- You may have noticed the StdLog command discussed in the second part of this article contains output from several other MacsBug commands. That's because StdLog is actually a MacsBug macro, or a sequence of other commands separated by semicolons. You can use the help command to see what commands are in a macro: type "help stdlog" to see the full expansion of the StdLog macro.

Generally, non-programmers don't need to define macros. However, MacsBug has two reserved macro names - FirstTime and EveryTime - that can be useful for people running unattended servers. If they exist, the FirstTime macro is executed when MacsBug is loaded at startup, and the EveryTime macro is executed every other time MacsBug is invoked, whether by the user or as the result of a system error. Here are some common strategies for defining these macros:

Simple restart:

FirstTime: G
EveryTime: RS

Smarter restart:

FirstTime: DX OFF;G
EveryTime: STDLOG;RS

The first example tells MacsBug to resume execution when it's invoked at system startup, then has MacsBug restart the machine in the event of a system error. The second example is identical, except that it turns off user breaks in the FirstTime macro (see the DX command, in part two of this article), and tries to make a standard log and restart the machine in the event of a system error - that way there's a record that the machine is having problems. Note that commands are separated by semicolons.

<http://db.tidbits.com/article/05130>

You can use the RB command instead of RS in these macros, if you like. Be sure the last command in the FirstTime macro is G, or the Mac will never continue starting up. Also, don't end the EveryTime macro with G, or you'll never be able to get into MacsBug.

The FirstTime and EveryTime macros must be defined as permanent macros before you can use them to restart a machine. To do this, you use a resource editor like Apple's free ResEdit to define the macros and store them in a file.

<ftp://ftp.info.apple.com/Apple_Support_Area/ Apple_SW_Updates/US/Macintosh/Utilities/ ResEdit_2.1.3.sea.bin>

Although I can't give complete instructions about using ResEdit in this article, here are the steps for creating these macros:

• Make a copy of MacsBug. (You can throw it away later.)

• Using ResEdit, create a new, empty file, naming it clearly. (Mine is called "MacsBug Cheapo Restart".)

• Leaving your new file open, use ResEdit to open the copy of MacsBug. Find and open the TMPL resources, select the mxbm resource (it should be the first one listed), then choose Copy from the Edit menu.

• Paste the mxbm template into your empty file, then close the copy of MacsBug. The only file ResEdit should have open now is your new file.

• Choose Create New Resource from the Resource menu. You can either type mxbm (all lowercase) or select mxbm from the scrolling list, then click OK. ResEdit creates the new resource and immediately opens it for editing.

• Click the resource entry, 1) *****, then choose Insert New Field(s) from the Resource menu.

• In the Macro name box, type FirstTime. In the Expansion box, type your FirstTime macro. (You can just type the letter G for now - you can always edit this later with ResEdit.)

• Click the second entry, 2) *****, and choose Insert New Field(s) from the Resource menu.

• In the Macro name box, type EveryTime. In the Expansion box, type your EveryTime macro. (Again, you can just type RS for now, and change it later if you like.)

• Choose Save from the File menu, and quit ResEdit.

• Move the file to the MacsBug Preferences folder inside your System Folder's Preferences folder. It will probably be the only file in that folder.

• You're done! The macros will start working when you restart the machine. If you want to disable them, move the file out of the MacsBug Preferences folder and restart.

Beyond Merely Geeky -- I still won't pretend that using MacsBug is for everyone. However, I hope you can see that its utility isn't limited to code-heads who drink too many carbonated beverages. Knowing the basics of using MacsBug can help you understand and troubleshoot software problems, which in turn makes your Mac more stable and using you Mac more productive. In the end, that's what everyone wants.

Hide full article

MacTech Conference, for IT Pros and Apple developers, is Nov 3-5,
in Los Angeles. The 3-day event is packed with sessions & evening
activities. Learn from the best. Meet and spend time with peers.
TidBITS readers save $50 at <http://macte.ch/conf_tidbits>!