Forgot your password?
typodupeerror
Programming Books Media Book Reviews IT Technology

Debugging 290

Posted by timothy
from the unlousy dept.
dwheeler writes "It's not often you find a classic, but I think I've found a new classic for software and computer hardware developers. It's David J. Agan's Debugging: The 9 Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems." Read on for the rest.
Debugging: The 9 Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems
author David J. Agans
pages 192
publisher Amacom
rating 9
reviewer David A. Wheeler
ISBN 0814471684
summary A classic book on debugging principles

Debugging explains the fundamentals of finding and fixing bugs (once a bug has been detected), rather than any particular technology. It's best for developers who are novices or who are only moderately experienced, but even old pros will find helpful reminders of things they know they should do but forget in the rush of the moment. This book will help you fix those inevitable bugs, particularly if you're not a pro at debugging. It's hard to bottle experience; this book does a good job. This is a book I expect to find useful many, many, years from now.

The entire book revolves around the "nine rules." After the typical introduction and list of the rules, there's one chapter for each rule. Each of these chapters describes the rule, explains why it's a rule, and includes several "sub-rules" that explain how to apply the rule. Most importantly, there are lots of "war stories" that are both fun to read and good illustrations of how to put the rule into practice.

Since the whole book revolves around the nine rules, it might help to understand the book by skimming the rules and their sub-rules:

  1. Understand the system: Read the manual, read everything in depth, know the fundamentals, know the road map, understand your tools, and look up the details.
  2. Make it fail: Do it again, start at the beginning, stimulate the failure, don't simulate the failure, find the uncontrolled condition that makes it intermittent, record everything and find the signature of intermittent bugs, don't trust statistics too much, know that "that" can happen, and never throw away a debugging tool.
  3. Quit thinking and look (get data first, don't just do complicated repairs based on guessing): See the failure, see the details, build instrumentation in, add instrumentation on, don't be afraid to dive in, watch out for Heisenberg, and guess only to focus the search.
  4. Divide and conquer: Narrow the search with successive approximation, get the range, determine which side of the bug you're on, use easy-to-spot test patterns, start with the bad, fix the bugs you know about, and fix the noise first.
  5. Change one thing at a time: Isolate the key factor, grab the brass bar with both hands (understand what's wrong before fixing), change one test at a time, compare it with a good one, and determine what you changed since the last time it worked.
  6. Keep an audit trail: Write down what you did in what order and what happened as a result, understand that any detail could be the important one, correlate events, understand that audit trails for design are also good for testing, and write it down!
  7. Check the plug: Question your assumptions, start at the beginning, and test the tool.
  8. Get a fresh view: Ask for fresh insights, tap expertise, listen to the voice of experience, know that help is all around you, don't be proud, report symptoms (not theories), and realize that you don't have to be sure.
  9. If you didn't fix it, it ain't fixed: Check that it's really fixed, check that it's really your fix that fixed it, know that it never just goes away by itself, fix the cause, and fix the process.

This list by itself looks dry, but the detailed explanations and war stories make the entire book come alive. Many of the war stories jump deeply into technical details; some might find the details overwhelming, but I found that they were excellent in helping the principles come alive in a practical way. Many war stories were about obsolete technology, but since the principle is the point that isn't a problem. Not all the war stories are about computing; there's a funny story involving house wiring, for example. But if you don't know anything about computer hardware and software, you won't be able to follow many of the examples.

After detailed explanations of the rules, the rest of the book has a single story showing all the rules in action, a set of "easy exercises for the reader," tips for help desks, and closing remarks.

There are lots of good points here. One that particularly stands out is "quit thinking and look." Too many try to "fix" things based on a guess instead of gathering and observing data to prove or disprove a hypothesis. Another principle that stands out is "if you didn't fix it, it ain't fixed;" there are several vendors I'd like to give that advice to. The whole "stimulate the failure, don't simulate the failure" discussion is not as clearly explained as most of the book, but it's a valid point worth understanding.

I particularly appreciated Agans' discussions on intermittent problems (particularly in "Make it Fail"). Intermittent problems are usually the hardest to deal with, and the author gives straightforward advice on how to deal with them. One odd thing is that although he mentions Heisenberg, he never mentions the term "Heisenbug," a common jargon term in software development (a Heisenbug is a bug that disappears or alters its behavior when one attempts to probe or isolate it). At least a note would've been appropriate.

The back cover includes a number of endorsements, including one from somebody named Rob Malda. But don't worry, the book's good anyway :-).

It's important to note that this is a book on fundamentals, and different than most other books related to debugging. There are many other books on debugging, such as Richard Stallman et al's Debugging with GDB: The GNU Source-Level Debugger. But these other texts usually concentrate primarily on a specific technology and/or on explaining tool commands. A few (like Norman Matloff's guide to faster, less-frustrating debugging ) have a few more general suggestions on debugging, but are nothing like Agans' book. There are many books on testing, like Boris Beizer's Software Testing Techniques, but they tend to emphasize how to create tests to detect bugs, and less on how to fix a bug once it's been detected. Agans' book concentrates on the big picture on debugging; these other books are complementary to it.

Debugging has an accompanying website at debuggingrules.com, where you can find various little extras and links to related information. In particular, the website has an amusing poster of the nine rules you can download and print.

No book's perfect, so here are my gripes and wishes:

  1. The sub-rules are really important for understanding the rules, but there's no "master list" in the book or website that shows all the rules and sub-rules on one page. The end of the chapter about a given rule summarizes the sub-rules for that one rule, but it'd sure be easier to have them all in one place. So, print out the list of sub-rules above after you've read the book.
  2. The book left me wishing for more detailed suggestions about specific common technology. This is probably unfair, since the author is trying to give timeless advice rather than a "how to use tool X" tutorial. But it'd be very useful to give good general advice, specific suggestions, and examples of what approaches to take for common types of tools (like symbolic debuggers, digital logic probes, etc.), specific widely-used tools (like ddd on gdb), and common problems. Even after the specific tools are gone, such advice can help you use later ones. A little of this is hinted at in the "know your tools" section, but I'd like to have seen much more of it. Vendors often crow about what their tools can do, but rarely explain their weaknesses or how to apply them in a broader context.
  3. There's probably a need for another book that takes the same rules, but broadens them to solving arbitrary problems. Frankly, the rules apply to many situations beyond computing, but the war stories are far too technical for the non-computer person to understand.

But as you can tell, I think this is a great book. In some sense, what it says is "obvious," but it's only obvious as all fundamentals are obvious. Many sports teams know the fundamentals, but fail to consistently apply them - and fail because of it. Novices need to learn the fundamentals, and pros need occasional reminders of them; this book is a good way to learn or be reminded of them. Get this book.


If you like this review, feel free to see Wheeler's home page, including his book on developing secure programs and his paper on quantitative analysis of open source software / Free Software. You can purchase Debugging: The 9 Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

This discussion has been archived. No new comments can be posted.

Debugging

Comments Filter:
  • by Anonymous Coward on Tuesday February 24, 2004 @03:42PM (#8376753)
    cause when i do it, it is often re-bugging
    • by Rick the Red (307103) <Rick.The.Red@gmail. c o m> on Tuesday February 24, 2004 @04:04PM (#8377038) Journal
      I find the best way to uncover bugs is to do a demo for your boss's boss.
    • by Frymaster (171343) on Tuesday February 24, 2004 @04:33PM (#8377381) Homepage Journal
      cause when i do it, it is often re-bugging

      we have a special process we call "debuggery". debuggery - maxims and arrows

      1. be hostile: your application was your friend - your baby. you gave it life. well, no longer. now your application is your enemy. do you admire the intricate house of cards you have built like hiram abif? don't. you have a glue gun now and you are going to do a little explaining about who is boss here! your app is taunting you - it's thinking "what does a chemical/analogue hack like that have that i don't?" well, i'll tell you: an index finger. suitable for hitting the "del" key. make this crystal goddamn clear!
      2. kludge everything! the debug stage of the development life cycle is all about kludges. we call it klop - kludge-oriented programming:

        kludge foo = new kludge(specialCase bar);

        you've written that. the debugging phase comes at the end of a project. ie the part closest to the deadline when clueless suits and moneyment confuse line count with product. the pressure is on. the company is on the line. are you going to walk into the glass tower and pitch to the vc's about how yr going to have to go back to the uml's and rebuild x? good luck! can i have your job when you're done? get the tape, get the staples, get the glue.

      3. blame others: teamwork is just a code word for being the shepherd to a flock of scapegoats. if you were smart, you'd have been working on cultivating a culture of accepting blame early on in the cycle. this is espescially effective if yr building a client/server thingy. establish early on that most of the failures are on the client(server) side. whichever one you're not writing.

        make yourself documentation czar if possible - then abuse the position to retroactively assign blame to other team members ("the docs explicitly state that we use roman numerals" - "gee, i don't remember that" - "well tough. get coding").if you set it up right you can build an army of debugging minions to do your kluding for you while you, uh, read slashdot...

      4. redefine feature sets. the client is a clueless little doughboy who can't tell his ass from his operating system anyway. he's been flaking you on the spec-n-req all year. turn those tables! if a feature is buggy, yank it. if there's a complaint, reference the client to some vaguely-related advisory somewhere (trust me, he won't read all the way down). if he complains say "in light of advisory x we strongly adivse against implementing _______ (feature). a work around may be possible at a future point and we are more than willing to calculate the billing for that additional work now."
      all that and echo will solve all yr debuggery problems.
      • I like your methodology and I would apply it in the case I do any debugging. I don't need it right now, because I didn't found any bugs to fix. It may be related to not doing any testing. Testing is dangerous, something may break. The only maxim I need is "if it compiles, it works". Modern compilers check your program, if I would make some silly error it just catches at sight. And static type checking guarantees the program works right allways. I never look the code again once it compiles. Isn't programming
  • #9 is wrong (Score:5, Funny)

    by Anonymous Coward on Tuesday February 24, 2004 @03:46PM (#8376808)
    What if someone else fixes it?
  • yuck (Score:5, Funny)

    by theMerovingian (722983) on Tuesday February 24, 2004 @03:47PM (#8376810) Journal
    Make it fail: Do it again, start at the beginning, stimulate the failure, don't simulate the failure, find the uncontrolled condition that makes it intermittent, record everything and find the signature of intermittent bugs, don't trust statistics too much, know that "that" can happen

    Isolate the key factor, grab the brass bar with both hands (understand what's wrong before fixing), change one test at a time, compare it with a good one, and determine what you changed since the last time it worked.

    Does anyone else feel dirty after reading this?

    • Re:yuck (Score:2, Insightful)

      by kooso (699340)
      Not me. It would be interesting to have a rule of thumb for the real economic cost of debugging this way.

      We all (except Dijstra [utexas.edu], perhaps) take trade-offs, for a reason. Perhaps that reason is only ignorance, but then we wouldn't get anything done.
  • by tcopeland (32225) * <tom&thomasleecopeland,com> on Tuesday February 24, 2004 @03:47PM (#8376822) Homepage
    > Change one thing at a time: Isolate the
    > key factor, grab the brass bar with both
    > hands (understand what's wrong before fixing),
    > change one test at a time, compare it with a
    > good one, and determine what you changed
    > since the last time it worked.

    This is helpful with unit tests, too. If I find a bug, I want to figure out which unit test should have caught this and why it didn't. Then I can either fix the current tests, or add new ones to catch this.

    Either way, if someone reintroduces that particular bug it'll get caught by the unit tests during the next hourly build [ultralog.net].
    • Unit Test? (Score:4, Funny)

      by MooseByte (751829) on Tuesday February 24, 2004 @04:23PM (#8377273)

      What is this "unit test" you refer to? If we consider our customer base to be a "unit", does that count?

      Yours Truly (All Belongs To Me),

      Bill
    • by wrp103 (583277) <Bill@BillPringle.com> on Tuesday February 24, 2004 @04:38PM (#8377446) Homepage

      It is nice to see a book that addresses this topic. I get very frustrated with so many text books that have at most a small chapter on debugging. Let's face it, beginning programmers spend more time debugging code than they do writing code, so why isn't that activity stressed?

      I particularly liked the rule about "Quit thinking and look". I worked with a guy who used what I call the "Zen method of debugging". He would keep staring at the code, trying to determine what was going on. I, on the other hand, would throw in some print statements so I could see what was going on. In one case, he insisted there was nothing wrong with the code, but what he didn't realize was that an early test failed, which meant the code he was looking at never got executed. I had suggested he print something out at the start of the routine, but he insisted it wasn't necessary because he knew what it was doing.

      He might cover this in the book, but one rule that I stress with my students is, if you make a change and the behavior of the program is the same, back out your changes because either:

      • You are probably looking in the wrong place (which is why the behavior is the same)
      • You could easily have just inserted several new bugs that you won't see until the path you are looking at gets executed.

      I often have students insist that their changes should have fixed something, but it turns out the program was actually executing an alternative path that they weren't looking at, or that the problem was much earlier, so when it got to where they thought the problem was, the data was different than they assumed.

      • by CargoCultCoder (228910) on Tuesday February 24, 2004 @06:01PM (#8378455) Homepage

        I particularly liked the rule about "Quit thinking and look". I worked with a guy who used what I call the "Zen method of debugging". He would keep staring at the code, trying to determine what was going on...

        Personally, I would consider this to be the anti-Zen method. He was apparently focused so much on what he "knew" to be true, that he failed to consider clues trying to point him in another direction. That is not the Zen way of looking at things.

        Zen and the Art of Motorcycle Maintenance [amazon.com] has a lot to say about this. If you're stuck on a problem, the solution is not to beat on it harder (e.g., stare at the code some more). The solution is to back off, and (to paraphrase from memory) allow yourself to become aware of the one little fact that's out there, waving it's hand, hoping that you might notice it ... and that'll point you at the real problem.

        Stupidly staring at code is not Zen. Having an open mind for interesting and helpful facts -- whatever their source -- is.

      • I particularly liked the rule about "Quit thinking and look". I worked with a guy who used what I call the "Zen method of debugging". He would keep staring at the code, trying to determine what was going on. I, on the other hand, would throw in some print statements so I could see what was going on.

        Sometimes reading the code is enough. If you're good at reading code, then sometimes all you have to do is briefly look over what you wrote to spot the bug. YMMV, of course. If you've looked at the code for
  • Heisenbugs... (Score:5, Informative)

    by Aardpig (622459) on Tuesday February 24, 2004 @03:48PM (#8376829)

    ...are always the worst: bugs which disappear when you look for them. Insert a print statement? The bug disappears. Use a debugger? The bug reappears, but in a different place.

    Heisenbugs are almost always caused by buffer overflows. They can often be prevented (at least in Fortran 77/90/95/03) by enabling array-bounds checking at compile time; but before I knew about this, I had a hell of a time tracking them down.

    • by AndroidCat (229562) on Tuesday February 24, 2004 @03:56PM (#8376953) Homepage
      When I was working on arcade games, we had a sure-fire method of making bugs go away. However, shipping each coin-op game with an engineer and $40k worth of testing equipment connected to it wasn't really cost-effective.
    • Sonuvabitch! (Score:3, Interesting)

      by Anonymous Coward
      Like 15 years ago in my intro CSE class my first Fortran program which found "edges" in a text file filled with numbers did this. Everything looked good. It would compile. But wouldn't print out its little thing. So I instert statements to print out status of where it is, and it works! I take out the statements and it doesn't. In/out in/out. SO I go ask the TA for help. He says its one of the damndest things he's seen, sorry, Fortran isn't something he's really an expert at.

      I have hated fortran for
      • Re:Sonuvabitch! (Score:4, Informative)

        by Aardpig (622459) on Tuesday February 24, 2004 @04:07PM (#8377072)

        I have hated fortran for years, having written a single program in it, based on this.

        Fortunately, things have changed a lot since then. With the introduction of modules and array arithmetic in Fortran 90/95, sitations where routines are called with the wrong arguments, or arrays are subscripted incorrectly, are much less frequent. I haven't been bitten by a Heisenbug for a couple of years now; and when I am, switching on checking at compile and run time usually reveals the problem pretty quickly.

    • Re: Heisenbugs... (Score:4, Interesting)

      by gidds (56397) <slashdot@gRASPidds.me.uk minus berry> on Tuesday February 24, 2004 @04:01PM (#8376998) Homepage
      You're describing bugs which are reproducible, but only on the unchanged code.

      Worse even that those are bugs which aren't reproducible at all, where there's no way to determine the conditions that caused them, or be sure you've fixed them. The only way to handle them is to fill the code with assertions and defensive code, and hope that at some point it'll catch something for you...

    • Re:Heisenbugs... (Score:5, Insightful)

      by WayneConrad (312222) * <wconrad@@@yagni...com> on Tuesday February 24, 2004 @04:04PM (#8377029) Homepage

      Heisenbugs are almost always caused by buffer overflows.

      They are also almost always caused by race conditions, the most insidious of which is thread-safe code that turns out only to be safe on a uniprocessor system.

      And don't forget the phase of the moon, or for the truly unlucky, intermittently glitchy hardware.

      • Re:Heisenbugs... (Score:3, Interesting)

        by jimsum (587942)
        Heisenbugs are also caused by floppy disks. We once shipped a program where one bit was wrong on the floppy, which caused a nasty bug. That one was hard to duplicate until we got the customer to ship us their version of the program.
      • Phase of the Moon (Score:4, Interesting)

        by cpeterso (19082) on Tuesday February 24, 2004 @05:51PM (#8378298) Homepage

        There really was a bug based on the phase of the moon. See the Jargon Dictionary for more info: phase of the moon [astrian.net]:


        phase of the moon
        phase of the moon n. Used humorously as a random parameter on which something is said to depend. Sometimes implies unreliability of whatever is dependent, or that reliability seems to be dependent on conditions nobody has been able to determine. "This feature depends on having the channel open in mumble mode, having the foo switch set, and on the phase of the moon." See also heisenbug.

        True story: Once upon a time there was a program bug that really did depend on the phase of the moon. There was a little subroutine that had traditionally been used in various programs at MIT to calculate an approximation to the moon's true phase. GLS incorporated this routine into a LISP program that, when it wrote out a file, would print a timestamp line almost 80 characters long. Very occasionally the first line of the message would be too long and would overflow onto the next line, and when the file was later read back in the program would barf. The length of the first line depended on both the precise date and time and the length of the phase specification when the timestamp was printed, and so the bug literally depended on the phase of the moon!

        The first paper edition of the Jargon File (Steele-1983) included an example of one of the timestamp lines that exhibited this bug, but the typesetter `corrected' it. This has since been described as the phase-of-the-moon-bug bug.

        However, beware of assumptions. A few years ago, engineers of CERN (European Center for Nuclear Research) were baffled by some errors in experiments conducted with the LEP particle accelerator. As the formidable amount of data generated by such devices is heavily processed by computers before being seen by humans, many people suggested the software was somehow sensitive to the phase of the moon. A few desperate engineers discovered the truth; the error turned out to be the result of a tiny change in the geometry of the 27km circumference ring, physically caused by the deformation of the Earth by the passage of the Moon! This story has entered physics folklore as a Newtonian vengeance on particle physics and as an example of the relevance of the simplest and oldest physical laws to the most modern science.
    • Re:Heisenbugs... (Score:5, Insightful)

      by kzinti (9651) on Tuesday February 24, 2004 @04:09PM (#8377107) Homepage Journal
      Heisenbugs are almost always caused by buffer overflows.

      In my experience, Heisenbugs are almost always caused by stack problems. That's why they go away when you put print statements in the code - because you're causing the usage of the stack to change.

      Buffer overflows (to arrays on the stack) are one good way to munge the stack. Returning the address of an input parameter or automatic variable is another way, because these are declared on the stack and cease to exist when the enclosing block exits. Anybody else using such an address is writing into the stack in an undefined manner, and chaos can result!
      • Re:Heisenbugs... (Score:5, Interesting)

        by Rufus88 (748752) on Tuesday February 24, 2004 @05:13PM (#8377808)
        In my experience, Heisenbugs are often the result of race conditions between concurrent threads.

        This reminds me of a famous hardware "bug":
        > This is a weird but true story (with a moral) ...
        > A complaint was received by the Pontiac Division of General Motors:
        >
        > "This is the second time I have written you, and I don't blame you for not
        > answering me, because I kind of sounded crazy, but it is a fact that we
        > have a tradition in our family of ice cream for dessert after dinner each
        > night.
        >
        > But the kind of ice cream varies so, every night, after we've eaten, the
        > whole family votes on which kind of ice cream we should have and I drive
        > down to the store to get it. It's also a fact that I recently purchased a
        > new Pontiac and since then my trips to the store have created a problem.
        >
        > You see, every time I buy vanilla ice cream, when I start back from the
        > store my car won't start. If I get any other kind of ice cream, the car
        > starts just fine. I want you to know I'm serious about this question, no
        > matter how silly it sounds: 'What is there about a Pontiac that makes it
        > not start when I get vanilla ice cream, and easy to start whenever I get any
        > other kind?'"
        >
        > The Pontiac President was understandably skeptical about the letter, but
        > sent an engineer to check it out anyway. The latter was surprised to be
        > greeted by a successful, obviously well educated man in a fine neighborhood.
        >
        > He had arranged to meet the man just after dinner time, so the two hopped
        > into the car and drove to the ice cream store. It was vanilla ice cream
        > that night and, sure enough, after they came back to the car, it wouldn't
        > start.
        >
        > The engineer returned for three more nights. The first night, the man got
        > chocolate. The car started. The second night, he got strawberry. The car
        > started. The third night he ordered vanilla. The car failed to start.
        >
        > Now the engineer, being a logical man, refused to believe that this man's
        > car was allergic to vanilla ice cream. He arranged, therefore, to continue
        > his visits for as long as it took to solve the problem. And toward this end
        > he began to take notes: he jotted down all sorts of data, time of day, type
        > of gas used, time to drive back and forth, etc.
        >
        > In a short time, he had a clue: the man took less time to buy vanilla than
        > any other flavor. Why? The answer was in the layout of the store.
        >
        > Vanilla, being the most popular flavor, was in a separate case at the front
        > of the store for quick pickup. All the other flavors were kept in the back
        > of the store at a different counter where it took considerably longer to
        > find the flavor and get checked out.
        >
        > Now the question for the engineer was why the car wouldn't start when it
        > took less time. Once time became the problem-not the vanilla ice cream-the
        > engineer quickly came up with the answer: vapor lock. It was happening
        > every night, but the extra time taken to get the other flavors allowed the
        > engine to cool down sufficiently to start. When the man got vanilla, the
        > engine was still too hot for the vapor lock to dissipate.
        >
        > Moral of the story: even insane looking problems are sometimes real.
        • Re:Heisenbugs... (Score:3, Insightful)

          by kzinti (9651)
          In my experience, Heisenbugs are often the result of race conditions between concurrent threads.

          Yeah, but thread problems are so slippery, I don't even think of them as Heisenbugs. I think of them as Neutrinobugs.

          A stack-related Heisenbug (or really any kind of Heisenbug, for that matter) will always occur in the same place, given the same conditions. Always the same location, always the same stack trace. But when you stick in a print statement, the bug moves, or - worse - it goes away altogether. That'
      • Re:Heisenbugs... (Score:3, Informative)

        by composer777 (175489)
        Buffer overflows tend to be less obvious than passing a pointer to a block of data that is allocated locally outside the scope within which it is created. In fact, I've never seen a bug caused by passing back a pointer to locally allocated data outside of the scope of the block (or function) in which it was created. In other words, stack based Heisenbergs seem easy to avoid. I think that this kind of bug indicates that a programmer is completely clueless about how machine code is generated. However, buf
    • Re:Heisenbugs... (Score:3, Interesting)

      by morcheeba (260908) *
      that's funny... I just tracked one of these down that existed in our software - the optimized version ran differently than the non-optimized version. It turns out the bounds checker is in the non-optimized version, and a couple of places in the code used x[rand()]=y ... the bounds-checker (implemented as a macro which had side effects) *caused* the heisenbug!
    • Re:Heisenbugs... (Score:3, Informative)

      by JWW (79176)
      Wow, I didn't even know there WAS a Fortran 03.

      I've only ever used 77, but I knew 90 existed, I just thought it must've died off after that (I haven't used Fortran in almost 15 years).

      • Re:Heisenbugs... (Score:3, Informative)

        by Aardpig (622459)

        Wow, I didn't even know there WAS a Fortran 03.

        Strictly speaking, there isn't -- yet. It is currently in draft form, and will be formally released later on this year. Fortran itself is still being used extensively for numerical modelling, since it remains the leader performance-wise for such problems.

    • Re:Heisenbugs... (Score:4, Informative)

      by Marvin_OScribbley (50553) on Tuesday February 24, 2004 @04:51PM (#8377576) Homepage Journal
      Heisenbugs are almost always caused by buffer overflows.

      In my experience with embedded systems, a Heisenbug is almost always caused by un-initialized data. You wind up assuming a particular value whereas you originally didn't plan on doing that. What value the data actually turns out to be is highly dependant on things like where in memory the code loads, how big the executable is, and so forth. Adding debugging statements will shift all the code after it up in memory and often make the bug go away and behave differently.

      Another interesting bug that is unrelated to the Heisenbug is when you port (for example) ANSI C code from one platform to another and code that originally worked starts doing weird things. For example, the C compiler under a BSD would allow modulo 0 and produce a zero result, which was incidentally what was wanted. Moved the code to Linux and started getting core dumps, because modulo 0 was considered dividing by zero. Some problems like this actually turn out to be Heisenbugs, for example due to differences in the way memory is malloc-ed on different systems. For example, suppose you accidentally malloc a pointer rather then its contents. One one OS you wind up allocating more memory than you need, but have no problems because addresses start fairly low in memory. On another OS memory addresses start somewhere else and you start getting weird errors due to lack of memory.
  • I'd agree (Score:5, Informative)

    by scatterbrained (144748) on Tuesday February 24, 2004 @03:49PM (#8376839) Journal
    I've read it and it's a good book, but I would
    just borrow it from the library and then print
    out the poster to remember the 'rules'.

    There's not enough meat to keep it on my
    precious shelf space.

    • Good call. Someone did an "ask slashdot" about pc diagnostics and I mentioned this one.

      The rules are really pretty straightforward and simple... that's why I think they need to be repeated every so often.
  • by garethwi (118563) on Tuesday February 24, 2004 @03:50PM (#8376848) Homepage
    ...to learn how to debug. I only need my own sloppy code.
    • Yeah who needs a book?

      System.out.println("1");
      ComplexClassInstantiator _cci = new ComplexClassInstantiator((UtilType)ClassGrabber.g e tObjectFromDefaults(_a, _b, _kl1, _z56), new UtilSocket(_p23876, _p5541), new Runnable() { public void run() { runDataSetAnalysis(_p1, _p2, _paramClass); } });
      System.out.println("2");

      Output: 1
      [Error message]
      So obviously the error is in the line between the two print statements.

      So, I repeat, who needs a book?
    • ...because I get so much practice.
  • by mark99 (459508) on Tuesday February 24, 2004 @03:50PM (#8376853) Journal
    Regression test suites (if possible) should be maintained so that when bugs get fixed, they stay fixed.

    Just my 2 cents.
    • It's funny how much time a typical tester spends testing the code that's OK already (has been debugged/fixed) while not touching the bugs outside of the scope of regression test suite. I would mandate ad-hoc testing with periodical (two to three times during the product cycle, basically at two last milestones and in the final version) regression testing. Not the kind of "we've changed this from int to uint, execute your 10000 test cases" kind of stuff I'm seeing way too often. Testers get bored and become d
  • Good read (Score:5, Insightful)

    by GoMMiX (748510) on Tuesday February 24, 2004 @03:50PM (#8376857)
    "
    If you didn't fix it, it ain't fixed: Check that it's really fixed, check that it's really your fix that fixed it, know that it never just goes away by itself, fix the cause, and fix the process."

    I can think of a WHOLE lot of tech's and admin's who really need to follow number 9 a lot closer.

    Especially those Windows admins/techs who think 'restart' is the ultimate fix-all. Though, sadly, I suppose in many cases that's about all you can do with proprietary software. Well, that and beg vendors to fix the problem. (We all know how productive that is....)
    • Yeah, I can't tell you how many times, at all levels of my company, we are told simply to try it again, and to change the parameters and how the error must be "configurational".

      Try telling the client that what they want to do with our software and how they want to use it is a "configurational" problem and they're using our software incorrectly, and 9 times out of 10 the clients (in our case, major banks) will drop our software.

      But then again, Microsoft uses the "configuration" argument all the time with
    • Re:Good read (Score:5, Insightful)

      by swb (14022) on Tuesday February 24, 2004 @04:11PM (#8377126)
      No, it's number *5* that EVERYONE needs to remember to follow. I see way too many people (including myself in a hurry) changing more than one thing at a time and then immediately wondering what fixed or why it didn't get fixed.

      This is especially important when changing a second variable can actually mask the fix of the change of the first variable or cause a second failure that appears to be the same as the initial failure.

      I guess they should have added a rule 10: be patient and systematic. Obvious problems usually have non-obvious solutions, and a thorough examination of the situation is time consuming. Don't take short cuts or you might miss the problem.
      • Re:Good read (Score:3, Informative)

        by monique (10006)
        This is a great example of where version control systems can really save your butt. Even if you *have* changed multiple things, at least you have some idea of what changed between when you started hacking around to find the bug and when you found it.
    • Reboot seems to be the tech monkey equvalent of using convenient gotos or calling main() in highlevel code. In some cases, it's necessary, but in most cases, there should be a better way. Sometimes it's just a tradeoff for convenience, to which we can all relate.
  • by sohp (22984) <(snewton) (at) (io.com)> on Tuesday February 24, 2004 @03:51PM (#8376858) Homepage
    Nothing about writing code for a test case that exercises the bug, then rerunning it every time you make a change you think will fix the bug? Seems like a big oversight. Any program of reasonable size is going to require wasting a significant amount of time restarting and re-running to the point of failure, and with every manual check of the result, there's an increasing probability that fallible human will make a mistake.

    More programmers need to get Test Infected [sourceforge.net].
  • Soul of a New Machine [amazon.com] by Tracy Kidder [bookbrowse.com] (book teaser) [businessweek.com] My favorite chapter was The Case Of The Missing NAND Gate.
  • by ToSeek (529348) on Tuesday February 24, 2004 @03:52PM (#8376892)
    "The most likely source of the current bug is the fix you made to the last one."
  • by Dr_Marvin_Monroe (550052) on Tuesday February 24, 2004 @03:53PM (#8376895)
    These "rules" are great, but nothing beats the mystic power of a little goat blood and chicken bones waved over a misbehaving system.

    Without these, the average user might be tempted to try and fix it themselves.... Next thing, my job is being "offshored" to a phone bank in India.

    No, the chicken bones and a little incantation will keep my job right here, where it belongs.
    • RMS, is that you?

      note to moderators

      i love what RMS has done for Free Software. the comment above is a joke, take it as such.
    • by dwheeler (321049) on Tuesday February 24, 2004 @04:39PM (#8377454) Homepage Journal
      Indeed, casting the runes [catb.org] has been a successful debugging technique before.

      Here's the story from the Jargon File (under "casting the runes"): "A correspondent from England tells us that one of ICL's most talented systems designers used to be called out occasionally to service machines which the field circus had given up on. Since he knew the design inside out, he could often find faults simply by listening to a quick outline of the symptoms. He used to play on this by going to some site where the field circus had just spent the last two weeks solid trying to find a fault, and spreading a diagram of the system out on a table top. He'd then shake some chicken bones and cast them over the diagram, peer at the bones intently for a minute, and then tell them that a certain module needed replacing. The system would start working again immediately upon the replacement."

  • by aliens (90441) on Tuesday February 24, 2004 @03:53PM (#8376898) Homepage Journal
    10) Hammer.

    if 10 fails

    11) Shotgun.

    Congrats problem solved, human destressed.
  • Time (Score:5, Insightful)

    by quarkoid (26884) on Tuesday February 24, 2004 @03:53PM (#8376906) Homepage
    One thing's clear from looking at that list - spend more time on testing your code.

    Unfortunately, speaking as an ex-programmer, time is one luxury that PHBs don't afford their minions. A project needs to be completed and knocked out of the door as soon as possible. The less time spent on unnecessary work, the better.

    It is also unfortunate that PC users have been brought up expecting to have buggy software in front of them and expecting to have to reboot/reinstall. What motivation is there to produce bug free code when the users will accept buggy code?

    Ho well, at least I run my own company now - master of my own wallet - and can concentrate on quality solutions.
    • Re:Time (Score:3, Interesting)

      Yeah, the sad truth seems to be that when prioritizing general and regression testing seems to rank low on the list because it doesn't actually create new product (though it is of course necessary, we aren't selling our testing, we're selling our new code).

      With marketers and product managers and sales people all pushing our product and making wild promises about delivery dates and patch dates it becomes a fruitless effort to keep on top of the regression testing, and I've found that with the software at m
  • Sounds interesting (Score:5, Interesting)

    by pcraven (191172) <(paul) (at) (cravenfamily.com)> on Tuesday February 24, 2004 @03:53PM (#8376907) Homepage
    Teaching people how to debug isn't that easy. It requires some experience before they get the hang of it.

    I'm a stickler for labeling code often, and tracking changes released to production. Because of this, I often seem to be a stick in the mud when it comes to refactoring.

    Heavy refactoring makes your code nicer. But when you have to do a lot of debugging on something that worked be refactoring, you can start to appreciate that keeping the change set managable is a 'good thing'. (I do financial apps, so this may not work for everyone.)

    The things I see people fail at most is the ability to 'bracket' the problem. Go between code that works and doesn't work, filtering the problem down to something simple.

    The second thing is the inability of some people to go 'deep' in their debugging. Decompile the java/C#/whatever code, trace through the library calls, whatever.

    Its nice to see another good book on the market that seems to cover these topics.
  • Rule 0 (Score:5, Funny)

    by Anonymous Coward on Tuesday February 24, 2004 @03:54PM (#8376913)
    0. If you're a software guy blame it on hardware, if you're a hardware guy blame it on software.

    0.1. Blame it on the user.

    0.2. Blame it on your colleague.

    0.3. Blame it on your manager.

    0.4. Yell at the computer and tell it to work dammit!

    0.5. Put head on keyboard and sob.

    0.6. Read Slashdot.

    0.7. Post on Slashdot.

    0.8. Call it a feature not a bug.
  • by TheCrayfish (73892) on Tuesday February 24, 2004 @03:54PM (#8376915) Homepage
    You can read a sample chapter from the Debugging Rules book in PDF format by going here [debuggingrules.com]. (Requires the free Adobe reader [adobe.com].)
  • by ackthpt (218170) * on Tuesday February 24, 2004 @03:55PM (#8376930) Homepage Journal

    10. Code is _always_ Beta. It's never done until it's no longer in use or support no longer exists.

    9. The better the SDK, the more sophisticated the bugs.

    8. There's always more bugs in the other guy's (girl's) code.

    7. Declaring code bug-free is asking for it to fail at the worst possible time with the greatest visibility.

    6. A good design is as likely to have bugs as a bad one. Bugs are equal opportunity.

    5. Debugging time is inversely proportional to coding time.

    4. If it works the first time, there's a bug, but you won't find it until you roll it out.

    3. Debugging is fun. Really! It's when you run out of bugs that you should wonder if you got them all, that's not fun.

    2. The most difficult bugs to find are in the most straightforward looking code.

    1. That's not a bug, that's a feature.

    • 10. Code is _always_ Beta. It's never done until it's no longer in use or support no longer exists.

      What about the opposite. Anyone against versioning? Tried and failed in Google to find an "Against versioning" campagin. I mean, somebody must be out there who only wants version 1.0 for all software.

      I guess the issue is in the meaning we attach to version numbers. What about a program as a well-specified function that, once is implemented (at least for a fixed platform) needs no "enhancements"?

      (E.g. D
    • "Thats a feature" (Score:3, Insightful)

      by peter303 (12292)
      I am not surprised at the number of so-called bugs that turn out to be holes in the specifications or tests. Then I tell the complaintant "thats the design specification". Then they say "no, thats not" and give me the updated specification.

      In fact, popular bug-tracking databases like Scopus usually merge bugs and enhancement requests together, due to this ambiguity.
    • If it works the first time, there's a bug, but you won't find it until you roll it out.

      There truly is nothing more scary than a program that works the first time. You know there's a bug, but you cannot find it. It's sitting there, silently laughing at your vane attempts to distrurb it from it's hiding place with your testing.

      The bug plots against you, with an evil grin on it's face, biding its time until you finally decide that maybe, somehow, your code actually was correct the first time. Then, just

  • Number one (Score:2, Interesting)

    by Jooly Rodney (100912)
    Okay, haven't read the book, and I guess dhweeler is distilling the rules down to a soundbyte, but isn't #1 the most important and difficult part of debugging? I mean, if I knew system Foo ver. Bar had such-and-such an idiosyncrasy, I could code around it, but Googling for hours to find the one message board post that lets you Understand The System can be aneurysm-inducing. It's not even always the idiosyncrasies of a system -- the sheer volume of stuff you have to learn about I/O conventions, operating s
  • Race Conditions? (Score:5, Insightful)

    by Speare (84249) on Tuesday February 24, 2004 @04:03PM (#8377015) Homepage Journal

    Make It Fail is pretty hard to do when it comes to race conditions. This has got to be the most frustrating kind of bug. Others are referring to the Heisenbug which comes in a variety of flavors.

    Sometimes you don't KNOW when there's multiple threads or processes, or when there are other factors involved.

    Have you noticed that a new thread is spawned on behalf of your process when you open a Win32 common file dialog? Have you noticed that MSVC++ likes to initialize your memory to values like 0xCDCDCDCD after operator new, but before the constructor is called? It also overwrites memory with 0xDDDDDDDD after the destructors are called. And that it ONLY does these things when using the DEBUG variant build process? Did you know that .obj and .lib can be incompatible if one expects DEBUG and the other expects non-DEBUG memory management?

    Someone on perlmonks.org was just asking about a Heisenbug where just the timing of the debugger threw off his network queries. Add the debugger, it works. Take away the debugger, it fails. I've got a serial-port device which comes with proprietary drivers that seem to have the same sort of race condition.

    The top 9 rules mentioned here look great. But you could write a whole book on just debugging common race conditions for the modern multi-threaded soup that passes for operating systems, these days.

  • by mykepredko (40154) on Tuesday February 24, 2004 @04:05PM (#8377044) Homepage
    probably added a step stating that the problem symptoms and causes should be articulated clearly (probably between #3 and #4) before trying to fix anything. I've seen too many engineers/programmers/technicians list symptoms and attack them individually, only to discover that they were related.

    On the surface, this flies in the face of "divide and conquer" - but what I'm really saying here is make sure you have the problem bounded before you attack it.

    Also, with Step 9, I would have liked to see more emphasis on ensuring that nothing else is affected by the "fix". Making changes to code to fix a problem is often a one step forward and two steps backwards when you don't completely understand the function of the code that was being changed.

    All in all, an excellent book in a little understood area.

    myke
  • by deanj (519759) on Tuesday February 24, 2004 @04:06PM (#8377060)
    They missed a good one: explain the bug to someone.

    If you start explaining the bug to someone, there's a good chance in mid-explanation you'll realize a solution to the problem.

    Some school (can't remember which) had a Teddy Bear in their programming consulting office... There was a sign. "Explain it to the bear first, before you talk to a human". Silly as it sounds, people would do it, and a large portion of the time they'd never actually have to consult the staff... by explaining it to the bear, they solved the problem.

    Weird, but true.
    • Oops. I just posted almost exactly the same point in a rather more wordy way. We never had the bear, but we did joke about the "cardboard cutout" we'd use instead of an actual person. Presumably someone at the company had heard of the teddy bear in question and adapted it to our circumstances.

      Regardless, this is easily the single most important debugging tip and I heartily agree.

      Dave.
    • Is that why jdbgmgr.exe has a teddy bear icon, by any chance? I always wondered...
      • by Speare (84249) on Tuesday February 24, 2004 @05:22PM (#8377920) Homepage Journal

        No, that's a funny thing. I drew that bear icon over ten years ago when I was on the Win3.1 shell team. I didn't even know it still shipped in any MSFT product.

        The teddy bear is named Bear, and was the cuddly companion of one of the Windows 3.1 / Windows 95 shell team developers. He'd carry it *EVERYWHERE*. There are quite a few internal APIs called BunnyThis() or BearThat(), usually with generic numbers, because giving it a name would entice application writers to try to call it. (They're useless three-line internal helpers, but that didn't stop conspiratorial book-writers from trying to document them anyway.)

        Bear also appears in the Win3.1 credits, where I made portraits of spectacled Bill, bald Steve, and large-schnozzed Brad Silverberg.

        Now I don't have any Microsoft products at my house, anymore, except one outdated off-net machine which runs edutainment CD-ROMs for my daughter.

    • I agree, explaining it to someone else is a really good way to debug things. It's discussed in the book, it's just not identified as a "rule" per se. You're probably right, it should've been elevated to a rule or subrule. The book does have a funny story that one group used a mannequin and made everyone explain their inexplicable problems to the mannequin (same idea as the Teddy Bear). And yes, it worked for them, too!
  • Missing rule (Score:3, Insightful)

    by timdaly (539918) on Tuesday February 24, 2004 @04:06PM (#8377062)
    He missed a rule: Explain the bug to someone else.
    The second pair of eyes often finds the problem
    even if they don't have a clue what you are talking
    about.
  • A missing rule (Score:5, Insightful)

    by Tired and Emotional (750842) on Tuesday February 24, 2004 @04:10PM (#8377124)
    One rule he's missed is very important: Before making a measurement (like printing the value of a variable or changing something about the code) work out what answer you expect to see. Note well - do this before you look at the result. When you see something different, either its a symptom of the bug, or a symptom of you not yet understanding the system. Resolving this will either improve your understanding or turn up the problem.
    • Yes, work out the expected answer, and then write code to test for it. Not only will it prevent you from making a dumb mistake in doing the manual comparison, you then commit the test code and you've created a regression test in case that bug ever pops up again.
  • my review... (Score:2, Informative)

    Mr. Agans' book presents real life experiences, or as he calls them war stories and humor filled comment/anecdotes.

    I find myself chuckling and giggling along while reading this book, some of what he said brought back my own memories while working/debugging on my own software bug(s), or other people's bug(s) that I have somehow 'inherited' because they left the company, or are too busy on other projects to debug their own code. I like the metaphors that he uses to explain ideas or concepts that seems a bit
  • by BinBoy (164798) on Tuesday February 24, 2004 @04:13PM (#8377156) Homepage
    4. Divide and conquer: Narrow the search with successive approximation, get the range, determine which side of the bug you're on, use easy-to-spot test patterns, start with the bad, fix the bugs you know about, and fix the noise first.

    That's a very usueful rule. In nearly 20 years of programming I haven't found any tool or technique that works better than printf / std::cout / MessageBox and logging.

    Logging is especially important if your users aren't conveniently in the same building as you. When a customer has a problem I've never seen before, I usually tell them to run the program with the -log switch and send me the log. Nearly always this leads to the problem and I can fix the bug within minutes.

    Add logging to your app and you'll increase the number of hours you can sleep.

  • by severoon (536737) on Tuesday February 24, 2004 @04:13PM (#8377164) Journal

    Well, even though I think most people 'round these parts would agree with me that the book covers the fairly obvious, I will say this: it's absolutely necessary to have an "expert" write these things down because all too often, us developers try to proceed and get blocked by management. At my last job, we had a big problem with WebLogic transaction management, some bizarre confluence of events was causing a HeuristicMixedException to be thrown by the platform--by the way, WebLogic people, thanks a lot for naming this exception this way and taking the time to make sure it gets thrown in no less than six totally unrelated (as far as I can tell) circumstances. I love it when exceptions originate ambiguously, from several sources, and no one part of the platform has authority over the problem.

    This was a big enough problem that we had to set up a separate, isolated environment to figure out what was going on. 4 out of the 5 architects involved on the project (no it wasn't a huge project--you can see HME wasn't the only problem here) had cemented ideas about what was going wrong...none of them agreed of course...and we had no less than 3 managers with theories based on the idea that the Earth sweeps through an aether against which all things can be measured.

    The biggest issue with this testing environment was keeping everyone's mitts off of it, especially those people who didn't have to ask for permissions to the system (the architects, managers...in other words everyone). And the managers didn't agree that it was particularly important to record every step methodically, or limit the number of people making changes to the system to 1 at a time. Instead, they set up a war room and engaged in what I like to call: Fix By Chaotic Typing. (It's chaotic in the sense that, there are definitely patterns to the activity taking place, but you have to be Stephen Wolfram to find and understand them.)

    Needless to say, that didn't work. If I'd had access to this book, an authority willing to put the obvious in print might have bolstered my argument that we needed to take resources OFF this issue, not add more. Alas, it was not to be. The bigwigs decided that, since the current manpower wasn't able to track down this bug, it was time to bring in the high-priced WebLogic consultants. We got some 1st generation WebLogic people, 3 of them eventually, and they came in and immediately set themselves to the task of learning our business, telecommunications. And at a mere $150/hour, why not? (Management decided the bug was non-deterministic at some point and this assembly of people was given the informal team moniker: the Heuristics team. I preferred "the Histrionics team".)

    So I eventually teamed up with the lead architect on the project and we solved the problem by subterfuge. We had to intentionally set these people working in a direction--everyone, employees and WebLogic consultants alike--that was so off-the-track they actually didn't interfere with any part of the system likely containing the error. This gave us a reasonable amount of time and space to track down the bug in 3 days' time. At only the loss of 6 weeks and several thousand dollars in expenses alone for the WL consultants.

    sev

    • Actually, the 'too many cooks' problem has already been covered pretty thoroughly in The Mythical Man Month, but it does sound like this book might get a place beside MMM and be equally useful for steering managers.

      --Parity None
  • An extra rule (Score:5, Insightful)

    by MythMoth (73648) on Tuesday February 24, 2004 @04:17PM (#8377218) Homepage
    "Describe the problem to someone else."

    This is so effective that it doesn't require the person to whom you're explaining it to pay attention, or even understand. A manager will do ;-) Even when the person to whom you're explaining it is smart, alert, and interested, it's almost never them that fixes the bug.

    The process of describing the behaviour of the program as it ought to be versus the behaviour it is exhibiting forces you to step back and consider only the facts. This in turn is often enough to give you an insight into the disconnect between what's really happening and what you know should be happening.

    If you catch yourself saying "that's impossible" when debugging some particularly freaky bit of behaviour, it's definitely time to try this.

    The input of the other party is so irrelevant in this process that we used to joke about keeping a cardboard cut-out programmer to save wear and tear on the real ones...
  • by ValentineMSmith (670074) on Tuesday February 24, 2004 @04:20PM (#8377248)
    Was it just me or did anyone else get to the bottom of that bullet list and feel let down? Here I was expecting some sort of earth-shattering revelation, and all that the list shows are common sense rules. At the risk of sounding elitist, maybe this was epiphany for someone else. Lord knows it would be a revelation in our QA department, where the list consists of exactly one rule:

    1. -Grab a programmer

    But still... Someone made money off of that? Heck, look for my new book next week, "Walking to Peoria in 3,976,554 steps", with each step being "Place your rear foot 1.5 feet in front of your front foot."

  • by Flexagon (740643) on Tuesday February 24, 2004 @04:27PM (#8377322)

    A good list. As part of rule 8, it's often extremely helpful to look at the problem from a different level of abstraction than one normally would (e.g., different than you coded, or that you best understand it). This often exposes false assumptions that may be blocking a proper analysis.

    Successful debugging is a lot like any hard science, particularly if you are not, and cannot, become familiar with the entire system first. Your "universe" is the failing system. You develop hypotheses (failure modes and potential fixes) and run experiments (test them). You have solved the problem only if you completely close the loop (your fix worked, it worked in the way you expected, your hypothesis completely explains the circumstances, and peer review concurrs).

    A big part of the "art" is cultivating an attitude of how systems are stressed, and how they may fail under those stresses.

  • by Anonymous Coward on Tuesday February 24, 2004 @05:21PM (#8377913)

    My favorite quote on the subject of debugging:

    As soon as we started programming, we found to our surprise that it wasn't as easy to get programs right as we had thought. Debugging had to be discovered. I can remember the exact instant when I realized that a large part of my life from then on was going to be spent in finding mistakes in my own programs.


    -- Maurice Wilkes, 1949

    55 years later, programmers are still spending a large part of their lives finding bugs and fixing them...

    • by JPZ (42691) on Tuesday February 24, 2004 @07:42PM (#8379761)

      As soon as we started programming, we found to our surprise that it wasn't as easy to get programs right as we had thought. Debugging had to be discovered. I can remember the exact instant when I realized that a large part of my life from then on was going to be spent in finding mistakes in my own programs.

      -- Maurice Wilkes, 1949

      55 years later, programmers are still spending a large part of their lives finding bugs and fixing them...

      Even worse, they're probably still spending time finding and fixing bugs this Wilkes guy introduced...

  • by rumblin'rabbit (711865) on Tuesday February 24, 2004 @07:01PM (#8379296) Journal
    Find the simplest possible run that replicates the error. My favourite strategy. It's really worth while doing this. Related to rule 4, perhaps, but not the same thing.

    Examine the input data. Often it isn't a bug. Often the program is doing an entirely reasonable thing given the input data. Or perhaps the program mishandled bad input data (in which case it is a bug, but now you know what to look for).

  • Missed one (Score:3, Insightful)

    by dmiller (581) <djm@@@mindrot...org> on Tuesday February 24, 2004 @11:13PM (#8382048) Homepage

    There is one that appears to be left out (from the summary, perhaps not from the book - I haven't read it): fix it everywhere.

    Once you have found a bug, search the rest of your tree for similar bugs. Chances are that you will find and fix several. This is especially true of bugs caused by bad assumptions.

    FYI: This is one of the central audit methodologies of the OpenBSD project. It works much better for the BSDs as they keep the entire system in one CVS tree, rather than scattering it around FTP servers in the forms of tarballs. The whole system is readily available to search for entire classes of bugs.

  • by igomaniac (409731) on Wednesday February 25, 2004 @05:03AM (#8384050)
    I have a lot of experience in finding and fixing difficult bugs. In my experience, the most important thing you can do is when you find a bug, stop and think how you could have caught this bug automatically. If you practice this policy, you end up with very solid code. Basically, in the debug build, no function should ever crash the program no matter what garbage you put in the parameters - it should report an error and stop.

    I think writing solid code is all in the attitude of the programmers - I had one guy who had a memory overwrite bug that was corrupting some characters in his string table when he called a certain function. Do you know how he fixed it? He wrote some code that put the right characters back over the corrupted ones after the call to this function!!! If you have that attitude, things WILL blow up in your face...

"Consistency requires you to be as ignorant today as you were a year ago." -- Bernard Berenson

Working...