June 96 - Balance of Power
Balance of Power: Sleuthing Through Your Code
DAVE EVANS
The night was well advanced, but the bright glow of fluorescent
lamps misrepresented time. As I sat back in my comfortable chair,
rubbing tired eyes, I wondered what the venerable but fictional Mr.
Sherlock Holmes would offer me as advice. Perhaps because I was
so weary from the long hours of debugging, I easily imagined Mr.
Holmes sitting near me in a tweed suit smoking his pipe. Certainly
he would address me as he once addressed his compatriot Dr.
Watson, with a slightly condescending tone, and he would tell me
that in my debugging I was missing the key iota of information.
At that moment, a solitary number seemed brighter on my monitor. Perhaps I have an
overactive imagination, but it seemed as if MacsBug were magically illuminating that
crucial, overlooked information. My computer was at interrupt level 2, yet it was
waiting for a driver request to complete. How could I have missed the interrupt level
earlier? It was no wonder that the computer froze. My software had most likely called
the driver synchronously at exactly the wrong time. The voice of Mr. Holmes rang
again in my ears. This time he quoted from that unfortunate story "A Case of Identity
when he said, "It has long been an axiom of mine that the little things are infinitely the
most important.
Sir Arthur's famous detective was unsurpassed as an observer of detail. He believed
that keen attention to all things -- even the mundane -- was the key to good detective
work. In debugging software, I've found this advice is also true. Although many
software bugs can be solved quite easily, the most challenging problems demand more
attention. This is especially true of crashes or freezes in your software. To find the
detail we need for those, we often have to go below source-level tools and get
comfortable with lower-level aids.
In this column I'll take you through some low-level debugging techniques. I'll start
with basic strategy and then discuss particular methods and examples. Although many
details will be PowerPC-specific, much of the information here is useful on all
Macintosh computers.
THE STRATEGY OF A SLEUTH
The experienced engineer starts with a basic strategy when faced with a troublesome
software crash or freeze. The strategy is similar to Mr. Holmes's approach to solving
difficult crimes. Using the scientific method, he starts by collecting key information
and details. When he has finished researching, he begins to analyze the information and
eliminates hypothesis after hypothesis. Once close to a solution, he seeks out more
detail to narrow his suspects to a single culprit. Similarly, your strategy for
debugging software should start with careful observation and research. Then you
should hypothesize, test your theories, and collect more detail. This narrowing
approach will draw you closer to the pernicious coding error in your software.
It's tempting when faced with a difficult crash to experiment instead of researching it
first. But beware! Don't just reimplement your code with new approaches until it
stops crashing. Though some may cynically suggest that that's the Macintosh way to
program, don't be lulled into this strategy. I've found that it usually produces unstable
code and ultimately takes longer than researching the original problem.