| ||||||
|
| ||||||
|
In using computers, few experiences are more disheartening that to have the program you're working in "unexpectedly quit," and then realize that your past hour's work has gone unsaved. This doesn't happen to me very often, mainly because I do most of my drafting a word processing in Tex Edit Plus, which is a very stable application, but I do occasionally get nailed. "Why don't you just enable the auto-save feature?" I hear someone in the audience asking. Well, mainly because I frequently work with documents that I want to modify without changing the original, and it would be too much hassle to be constantly going into the Preferences to turn auto-save on an off; that is if I remembered to do it. Being absent-minded most of the time, this plan simply wouldn't work for me. Consequently, I rely on saving manually fairly often, which I remember to do on the sporadic basis, but program stability certainly helps. However, last week I was working on a column late in the evening. I was tired and somewhat distracted, and I forgot to save my work as I went along. I didn't even name the document. And of course, that was the time for Tex Edit Plus to uncharacteristically crash, just as I was spell checking the finished article with SpellTools. I really like SpellTools, but it can be a little flaky in the stability department at times. In this instance, I hadn't restarted the PowerBook for days, was up to "Untitled 96" or something like that in Tex Edit and had had or over 25 different applications open over the past several days. It stood to reason that the System memory was getting a little raggedy, although there had been no really notable warning symptoms in admirably resilient Mac OS 9.1. Anyway, SpellTools crashed and took Tex Edit with it, as well as my just-finished article. My heart sank. I was already tired, and while I had enough notes to reconstruct the article, it represented more than an hour of work on the final draft alone, and I really didn't what to rewrite it again. I recalled a similar incident several years ago on my old PowerBook 5300, where my Mac-guru son had used MacsBug to search the residual memory and managed to retrieve my entire lost article out of RAM. This is different from using programs like Norton's Unerase, because in both of the cases I'm citing, the work had never been saved to disk in the first place.
Unfortunately,Tristan no longer lives at home, so this time I was on my own. Right. I always keep MacsBug, Apple's freeware debugger program for developers, on my hard drive to assist in recovery from crashes in freezes. It allows me to get back to the Finder to save my work, close programs in an orderly fashion, and restart gracefully rather than using the dreaded three-finger salute (command - control - power key). MacsBug essentially gives you a command line interface to the guts of the Mac OS, which you address with Assembly Language, the basic OS's machine code. It is used by programmers to debug code running in most execution environments, from applications to drivers, and everything in between, and is often used as a bug-reporting tool by 3rd-party developers, as well as Mac OS system software developers. In most instances, MacsBug pops up automatically with a jarringly un-Mac-like screen (unfortunately, MacsBug disables screenshots) when you crash. You can also enter MacsBug by pressing command - power key. MacsBug 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 done, usually. Believe me, it is sometimes a life saver. 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 PowerKey, 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 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 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+PowerKey" force restart command. Anyway, back to the lost text. I remembered an article that I downloaded several years ago called "Cool MacsBug Tricks" by Macneil Shonle, and I wondered if the instructions for retrieving unsaved text from RAM would be included. I found the article in my archives, did a word search, and sure enough, there was the information I needed, or at least it seemed so. I am no programmer, and the instructions for getting one's text back, which Macneil obviously regarded as simplicity itself, seemed pretty arcane to me. Macneil instructed first to create a log of what ever MacsBug came up with in a text document on the desktop. You do this by typing "log" and then naming your log file something. I named mine "My Column." Then, to initiate a scan of the PowerBook's memory, Macneil said to use the "f" command, which stands for "find." and type in this string. f 0 (400 * 400 * 192) "key word" "f" stands for find. "0" is the beginning of memory. "400 * 400*" is exactly one megabyte of memory. At least that's what Macneil says. I'll take his word for it. The "192" stands for the number of megabytes of real RAM I have installed in my machine. Macneil said he had eight megabytes installed on his Mac. It is an old article. You also need a distinctive key word, preferably near the beginning of the text you are looking for, in quotes. I remembered at the beginning of my column I had referred to the reader with an unusual surname, so I used that for my key word. I then hit return, which initiated the search. This line appeared: Searching for "name" from 00000000 to 191FFFFF and sure enough, up popped a piece of text with the reader's name in it, along with this string of code: 05F8D3B3 4177 7777 7720 2D2D 2049 206C 696B 6520 name answer. Cool! This indicated that my key word could be found at memory address 00358200. (the leftmost number in the string). Macneil said at this point to type in the command "dma 05F8D3B3" (the leftmost number; dma stands for "display memory at") which I did, and then keep hitting return until the entire text of the lost article is shown in the MacsBug window. At that point you just type in "log" again to close the log, and exit MacsBug by typing "G" and hitting return, which gets you back to the Finder. The System memory had been too corrupted by the application crashes to allow me to do anything other than quit each open program by going back to MacsBug (command - power key) and typing es (exit to shell) followed by the return key. Once all the applications has been closed, I returned to MacsBug and typed rs for "restart." Once the PowerBook was booted up again, I opened the "My Column" log document in Tex Edit, and there was my article -- with memory address numbers at the beginning of each line, no line breaks, and paragraph breaks represented by • • • . Still, going through the retrieved text, erasing the numbers, and restoring formatting was an awful lot easier than rewriting the article from scratch! I was happy. Now that I have successfully learned how to do this with MacsBug, I expect that I will be using this function again. It surely does take the sting out of losing unsaved data in a crash. I wouldn't want to be without MacsBug, and there is no reason to be. Just download a copy at this URL: <http://developer.apple.com/tools/debuggers/MacsBug/> (499K), drag the little MacsBug cherry bomb shaped icon into your System Folder, and restart. The rest of the stuff you get in the MacsBug download seems to be irrelevant for the purposes normal Mac users will put this software to.
Incidentally, as David Pogue notes, "MacsBug is neither extension nor application; it just kind of IS." I can't improve on that. A tip of the hat to David also for explaining that MacsBug stands for "Motorola Advanced Computer Systems deBugger." Once you have MacsBug installed in your System Folder, when you start up your computer, the "Welcome To Mac OS" screen will now also read "Debugger Installed." You can also open your System folder, turn on balloon help, point to the MacsBug icon, and be presented with an amusing message. MacsBug will not work with Mac OS X, and there is no need for it there, since you will be able to do similar tasks and more using Unix command lines. My son says this is better, I believe him, but it will involve another learning curve. For more on MacsBug: http://physics.clarku.edu/~mshonle/macsbug.html http://www.goingware.com/tips/macsbug.html Appendix MacsBug 6.6.3 Released September 14, 2000, this is the latest final version of MacsBug. This version works with all of the machines released in the Summer of 2000, including the Power Mac G4 (uni- and multi-processor), Power Mac G4 Cube, the new iMac family (Ruby, Indigo, Sage, Graphite, and Snow), and the new iBook family (Indigo, Key Lime, and Graphite) and earlier. It includes better support for debugging MP tasks, and fixes some serious bugs in the memory setting commands when used in PCI I/O space. Also available: MacsBug Reference and Debugging Guide 6.2 Released in 1991 (!), the is the latest final version of the MacsBug documentation. All files are in PDF form and require Adobe's Acrobat Reader to view. For more information, visit:
|
. |
| ||||
