The Six Stages of Debugging (2012)(plasmasturm.org)
plasmasturm.org
The Six Stages of Debugging (2012)
http://plasmasturm.org/log/6debug/
6 comments
1. This doesn't work, and I don't know why
2. I have no idea how this is supposed to work
3. Let's change some random thing that shouldn't be related at all
4. This works now, and I have no idea why
5. Pray to the gods of code that whatever it was that broke doesn't happen again
2. I have no idea how this is supposed to work
3. Let's change some random thing that shouldn't be related at all
4. This works now, and I have no idea why
5. Pray to the gods of code that whatever it was that broke doesn't happen again
From a recent meme:
99 little bugs in the code, 99 little bugs. Take one down, patch it in Prod, 117 little bugs in the code. -Attributed to Kurt Cobain
99 little bugs in the code, 99 little bugs. Take one down, patch it in Prod, 117 little bugs in the code. -Attributed to Kurt Cobain
I just sang this to my sister. She laughed, but doesn't understand. God, we're nerdy.
And then there is Joe's (Joe Armstrong) Law of Debugging :)
"All errors will be plus/minus three statements of the place you last changed the program".
This seems more accurate to me than the OP.
I had forgotten about this site and am pleased to get a reminder. Its the place I first saw the immortal quote:
A friend of mine in a compiler writing class produced a compiler with one error message “you lied to me when you told me this was a program”. —Pete Fenelon
http://plasmasturm.org/code/
A friend of mine in a compiler writing class produced a compiler with one error message “you lied to me when you told me this was a program”. —Pete Fenelon
http://plasmasturm.org/code/
Do yourself a huge favor and skip steps 1-3. Have a deep, abiding, instinctual faith in your own incompetence.
Until you hit a compiler bug. I'll never forget a certain PIC C compiler that would only ever take the first case in a switch statement, and how long it took me to believe that my code was actually fine but that the compiler wasn't.
This one made me swear a lot:
http://support.microsoft.com/kb/842136
... remote login to a windows 2003 server changes the default locale, breaking servers that depend on the default locale (which of course they shouldn't!). When this bit us, we were working on the server in a different room from a guy who was very occasionally logging in remotely, as I recall we only realised when he left his door open and we saw the two things happen at once.
... remote login to a windows 2003 server changes the default locale, breaking servers that depend on the default locale (which of course they shouldn't!). When this bit us, we were working on the server in a different room from a guy who was very occasionally logging in remotely, as I recall we only realised when he left his door open and we saw the two things happen at once.
I used to work with a guy who would blame every bug that cursory inspection couldn't uncover on the compiler. This is of course laughable, but he'd once, ages before, actually found a compiler bug. I wonder if having this amazing get-out-of-debugging card made him a jobsworth, or was simply a magical proof of "God takes care of fools and drunks."
Embarrassing story time: I was this guy at one point. I had the vast misfortune of finding a compiler bug early in my career. It was in a somewhat obscure variant of gcc cross-compiling for a slightly obscure architecture (PowerPC). I still remember learning PowerPC, reading through the code, and determining that it was indeed the dcc compiler at fault. It was, frankly, an awesome feeling. Especially because this bug took two weeks to track down.
My coworkers naturally doubted that I had found a compiler bug. Correspondence with the compiler's developer confirmed my initial finding. I was vindicated, and could prove I had caught one of the most reclusive bugs of them all.
Fast forward two years, and my coworker is having trouble with MSVC 6 (an old compiler, even at the time). The behaviour seems odd, and my mind jumps back to that one bug I found previously. We isolate it down to one line, and I state with confidence that the compiler generated incorrect code.
My coworker agreed at the time. But the next day, after re-reading the code, he pointed out that I had read it incorrectly. The compiler was doing exactly the right thing. To further my embarrassment, it wasn't even some obscure feature of C (like trigraphs). I made a common mistake and misunderstood basic pointer arithmetic. I still feel an urge to slam my head into my desk right now.
Morale of the story: compiler errors are rare. Really rare. I essentially caught bigfoot on my first hunting trip. Now I have to reassure myself I'm not seeing him again every time I'm confronted with a difficult debugging problem.
Or in technical terms, only declare you have found a compiler error if you have:
(1) read the generated assembly
(2) re-read the code several times alongside the relevant language specification
(3) developed a reproducible example
(4) formulated a plausible theory of what went wrong in the compiler, and contacted the vendor who has confirmed your suspicion
My coworkers naturally doubted that I had found a compiler bug. Correspondence with the compiler's developer confirmed my initial finding. I was vindicated, and could prove I had caught one of the most reclusive bugs of them all.
Fast forward two years, and my coworker is having trouble with MSVC 6 (an old compiler, even at the time). The behaviour seems odd, and my mind jumps back to that one bug I found previously. We isolate it down to one line, and I state with confidence that the compiler generated incorrect code.
My coworker agreed at the time. But the next day, after re-reading the code, he pointed out that I had read it incorrectly. The compiler was doing exactly the right thing. To further my embarrassment, it wasn't even some obscure feature of C (like trigraphs). I made a common mistake and misunderstood basic pointer arithmetic. I still feel an urge to slam my head into my desk right now.
Morale of the story: compiler errors are rare. Really rare. I essentially caught bigfoot on my first hunting trip. Now I have to reassure myself I'm not seeing him again every time I'm confronted with a difficult debugging problem.
Or in technical terms, only declare you have found a compiler error if you have:
(1) read the generated assembly
(2) re-read the code several times alongside the relevant language specification
(3) developed a reproducible example
(4) formulated a plausible theory of what went wrong in the compiler, and contacted the vendor who has confirmed your suspicion
This is a marvelous story, thanks.
Yeah, or VM/runtime bugs. I bet I go bald from that time I had to use Mono.
I've had many times where I swore that something was a compiler bug. I did hit one once with Haskell/ghc, but I think that is the only instance.
Was about to say that i usually seem to start at 4.
The Margaritaville stages of debugging:
1. It's nobody's fault
2. It could be my fault
3. It's my own damn fault
1. It's nobody's fault
2. It could be my fault
3. It's my own damn fault
I was merely going to append to OP's list:
7. Who wrote this crap?
8. Oh, I wrote this crap...
7. Who wrote this crap?
8. Oh, I wrote this crap...
I call this the "Kaiser Soze" bug. You spend hours trying to figure out what's causing a bug, only to realize you're the one who caused it.
The first time I saw this was on bash.org:
http://bash.org/?950581
http://bash.org/?950581
The "one day we will write tests" hits more than a little close to home.
The door to which they were taped was in IL2 and belonged to Mike Engber. He says, "The version on my door now is nicely laminated."
The list itself was created be me some years prior when we worked on Newton, after a particularly frustrating DMA debug session.