Low End Mac

 | 

Miscellaneous Ramblings

MacsBug 6.6, Apple’s Free ‘Crash’ Utility

Charles W Moore - 1999.11.01

1999: This week Apple released the final version of its Mac OS 9 compatible version of MacsBug app, version 6.6. MacsBug also finally has its own, dedicated web page on the Apple Website, where you can go to get information on or download the latest MacsBug version.

MacsBug is an acronym for Motorola Advanced Computer Systems deBUGger and is Apple’s assembly-level 680×0 and PowerPC debugger for the Mac OS. It is used by programmers to debug code running in most execution environments, from applications to drivers and everything in between, and it is often used as a bug-reporting tool by third-party developers, as well as Mac OS system software developers.

MacsBug Can Keep You Running After a Program Crash

However, MacsBug is also a very useful piece of software to have in your System Folder, even if you are a programming dunce like me. The main thing I find MacsBug useful for is getting out of crashes and screen lockups so I can save work and restart in an orderly fashion – or even continue working without restarting if I’m pressed for time.

Sometimes I will have programs crash to MacsBug three or four times a day and still be able to carry on for days without restarting my computer. Without MacsBug, each of those crashes would have involved a hard restart and the necessity of restarting the 15-20 programs I keep running all the time as well.

When MacsBug is installed, instead of a bomb dialog box or an “unexpectedly quit” or “system error” message showing up when a program crashes, you are presented with a funny looking, DOS-like screen, which can provide you with a comprehensive explanation of the problem, such as “illegal instruction” or “unimplemented trap” or somesuch at some address in some data space with other details you don’t care about. That’s usually not very helpful unless you understand programming code.

What is helpful is that you can type “es” (which stands for “ExitToShell”) into an entry field, press Return or Enter, and quite often be transported back to the Finder where you will still be able to do stuff – if only save your work. The prudent user will then quit all running programs and restart, which is still a lot better than losing unsaved work in other programs in a force restart. The unprudent user like me will keep right on computing and wait until the memory heap gets so corrupted that even MacsBug won’t get me out of it. However, no harm is done usually. In MacsBug 6.6, when you “es” (Exit to Shell), it now cleans up properly by patching ExitToShell.

If typing “es” doesn’t work, you’re no worse off and will usually end up back in the MacsBug window. I usually try “es” two or three times, and if that does not produce the desired result, I resign myself to the dreary task of restarting, which can also be done from the MacsBug window by typing “rs” (which stands for guess what?) and pressing Return or Enter. You can also (almost always) bring up the MacsBug window at any time by pressing Command and the power key, even if things have frozen but MacsBug has not appeared of its own accord.

Why would you want to do this?

Because the restart you get by pressing “rs” in MacsBug is different from the “Restart” command that the Finder offers. The Finder’s “Restart” command sends an Apple event to all programs, asking them to quit, turning off the hardware only when the Finder is all that’s left. The MacsBug “rs” command tries to unmount all of your online volumes and then toggles the hardware power, so you’ll lose any unsaved work in any application.

The main advantage to “rs” over the Finder’s “Restart” command (which is probably inaccessible anyway in a crash or freeze) is disk unmounting. If a disk isn’t unmounted correctly, the Mac OS realizes that something is wrong and goes through a time-consuming verification cycle the next time the disk is mounted (made available for use). But “rs” takes a crack at unmounting the disks before restarting, which could save some time. If that fails, “rb” tries to unmount only the boot volume before telling the hardware to restart. Either is better than simply pressing the power switch twice or using the time-honored “Command-Control-power key” force restart command.

These three useful commands: “es,” “rs,” and “rb,” are just the tip of the iceberg, so to speak, of what MacsBug is capable of, but they are the reason I wouldn’t want to be without it. If you don’t already have MacsBug, give it a try. It’s free! Just download, drop it in your System Folder, and forget it until you need it. Instructions for installing MacsBug are included in the ReadMe file with the download.

MacsBug 6.6 final, released on October 25, is the latest version of MacsBug and is the required version for Mac OS 9. It includes numerous bug fixes (yes, even a debugger can have bugs!) and cool new features. Highlights include basic support for the new PowerPC AltiVec (a.k.a. “Velocity Engine”) vector unit, initial mouse-based control (MacsBug finally has a cursor!), a rewritten Watch Points implementation that supports Mac OS 8.6 and 9.0, as well as numerous other changes.

Another new feature in MacsBug 6.6 is the add “DS” (Display memory Strings) command, which searches through memory and displays the first string of characters that match a given criteria. A valid string has only characters in the ASCII range 32 to 127 and has a minimum specified length, which defaults to five characters. The following example finds all strings in the current application heap that are at least 20 characters long:

DS InApp #20

A new experimental feature in MacsBug is a Menu Bar, which is off by default, but which can be dynamically enabled with the “SET MENUBAR” command. To enable the menu bar by default, copy the ‘mxpr’ and ‘TMPL’ resources from MacsBug into your “Debugger Prefs” file, then edit the ‘mxpr,’ and set the “Show MacsBug menu bar” bit.

Text is now highlighted in various colors to show errors, warnings, etc. Entering MacsBug 6.6 no longer causes the Macintosh to lose the network connection when booted from a NetBoot server. Note that MacsBug calls the G4 processor “7400 (G4)”.

Further Reading

keywords: macsbug

short link:  https://goo.gl/sqNazR