The first rule of debugging

If the bug isn't where you're looking, you're probably looking in the wrong place Seems pretty obvious, but I get nailed by it all the time: I get some preconcieved notion of where the problem is, and then I focus there to the exclusion of looking at other possibilities.

Readers of this blog may be wondering why It's been so long since I last added an entry. I write this blog using my own tool, which you can find at bloged.dev.java.net. It recently developed a problem that took me a long time to resolve - and it was a classic case of looking in the wrong place. Of course, the real reason that it took a long time to resolve is that I tried to write a blog entry with the new version, but that failed; then I couldn't look at the problem right away because there was other stuff I had to rush off to. It's a real problem when you have to debug things in 15 minute sessions, once a week.

Atsuhiko Yamanaka had been doing some excellent work adding security features to the ssh web site access facilities. He did a putback, I brought it over, rebuilt... boom it didn't work. And it didn't work in a perplexingly silent way. I was pretty surprised since Atsuhiko has done flawless work and I totally expected his stuff to fly. But this didn't - the problem was clearly in the code he had put back so that's where I was looking. But look as I might, I couldn't find the problem. I'll spare you the intervening gory details about the stupidly fruitless search for a problem in his perfect code. In the end it turned out to be totally elsewhere: I had leapt from the bringover/build/boom correllation to believing I knew where the bug was. But there were other things going on in the world. In this case, it was a configuration change in another part of the universe. I only found out about it when I sshed to the server, and that failed too..... A few minutes later, problem solved. Duh

September 13, 2003