What are your best practices for bugs that are hard to solve? [closed]

Answer 1

Walk through the code with a debugger, line by line. At the very least, this should pinpoint the line where something you don't understand is happening. If your initial guess at what the bug is fails, stop guessing and use a debugger.

Answer 2

Print outputs everywhere if you don't want to set breakpoints. Helps me big time when debugging. And then, of course when you see THAT variable output equals something totally different to what you thought it should, its like light breaking through.

Answer 3

Something I've found helpful is to bear in mind that, when dealing with the really interesting/nasty bugs, you don't have to hit the right solution all at once. Anything that tells you something you didn't already know represents a step in the right direction, and thus gets you closer to the answer. Even figuring out what the problem isn't helps, because you know to look someplace else.

Suspect that maybe the bug may be caused by condition X? Then try dialing X up to 11. If the bug gets worse (or shows up more frequently), X may indeed be your culprit. If it has no effect, look elsewhere.

Is the bug intermittent? Then temporarily forget about trying to figure out why it happens and focus on when. If you can come up with a test case that reliably reproduces the bug, you're well on your way to figuring it out.

Think one particular part of the code looks suspicious? Then sprinkle it liberally with breakpoints or print statements (as your environment allows) and prove to yourself it's behaving properly. Check the input variables. Check the output variables. Hell, maybe even check the environment variables.

When I'm stumped, I try to fall back on basic experimentation: gather data, form hypothesis, test hypothesis, lather, rinse, repeat. You know, toss some "science" into my Computer Science. :-)

Answer 4

I have to be good at finding and fixing bugs when I program like I do. ;)

First of all, I have to admit that the bug is mine. When working with a group it is easy to blame someone else for a problem. When I get that inclination, I start by collecting enough evidence to prove that the bug is theirs. About half the time, I collect enough evidence to determine that it is mine. By that time I'm well on my way to a solution. Otherwise I approach the other developer explaining what my code does, what the response is, and what surprises me about that response. That makes it easier for them to either point out where my expectations were wrong or where their contributions may not be working correctly.

When I do determine that the problem is mine, I approach it with "the relentless application of logic." I collect all of the information I can about the misbehavior. Then I examine it and the code side by side, trying to figure out what could cause unexpected behavior. Usually this points to some part of the code that becomes suspect. At that point I try to instrument the code further, saving copies of variables or logging critical information. Based on the further information collected, I evaluate and refine my original hypothesis and go on. Several such iterations usually nail down the bug or point to a new area for investigation. I guess that boils down to analyze -> instrument -> test -> repeat. When I find the problem, I always go through at least one more instrument -> test iteration to make sure the bug really is fixed.

As others have mentioned, ask coworkers for help. That helps in two ways. First, you will understand your code better when explaining it to them. Even if your coworkers are not at your level, this can help. Second, they may see things you did not notice or ask questions that did not occur.

Answer 5

In 3D (games, for example) rendering stuff, debugging is always a nightmare. It sometimes goes down to pixel debuggers, which displays when and during what draw call that pixel was modified, from what to what color.

Answer 6

I've found when staring at something that should be working but isn't, I'm often trying too hard. Grabbing a friend and explaining to them how it should work, line by line, bit by bit, usually causes the problem to jump out.