Slashdot Mirror
Mountain Biking Helps Squash Bugs
Dr.Milius writes "Henning Brauer of the OpenBSD project recently made an interesting post to the openbsd-tech mailing list about how a mountain bike ride helped him relate two baffling bugs in their new BGP and NTP daemons. It turns out they were both off-by-one errors that were easy to fix but notoriously difficult to spot. Always great when the experts show us how it's done."
Ride the fucking bicycle.
if you can't figure it out, stop trying so damn hard and just do something else.
I wonder what effect a road bike would have upon bugs? I mean, one could go faster in the flats where bugs are likely to reside, but at the same time, wider tires would allow one to run over more ants. Oh, the dillemmas!
This is something well known to work. It's not the bike riding, it's the act of "taking a break from the problem." Think back to the origins of "Eureka!"
I, for example, will often go grab a Coke, talk to people, etc, and somewhere along the line, by _not_ focussing so hard on the problem, I come up with the answer.
Error 407 - No creative sig found
It is ironic that people, on the one hand, fool themselves into thinking that these things don't happen to them, and on the other hand, have to go off bug hunting for days to find "baffling bugs". How much more productively could that development time have been spent?
Face it, memory corruption bugs, off-by-one-errors, and all that, happen to even the most experienced and careful programmers. The way to deal with them is to use programming languages that detect them reliably. In different words, we need to retire C or fix C.
And, no, "retiring C" doesn't mean switching to Java or C#. Instead, it means switching to a systems programming language that has error checking by default but still gives you all the low-level features you need when you need them. There have been a number of such languages over the years, but, unfortunately, they were all killed by C, not because C was better, but because C shipped with UNIX.
Every developper knows that... ;)
It happened to each of us, no need to be an expert or something: the bug drives you nuts, and you end up saying "fsck that" and go out, totally out of ideas. Then you smoke your cigarette of whatever, or go for a walk. And because you've sort of given up, you start to look at the problem in a different way, probably also because you're not in front of your screen and your brain is more "free", you realize that there are some obvious things that you didn't checked... And 5 minuts later, there is no more bug. That's why i go out to smoke a cig every hour (well not really, but still, it's a nice excuse
Besides, if you look at the well known "eureka" moments, it seems they all happened when the person was relaxing. Maybe we should be forced to relax each time we're facing an intellectual difficulty, really...
Hmm. Well, I did figure out how I wanted to implement a portion of my code when I was taking a crap recently.
On the food aspect, whenever I run into coding problems, I go bake cookies. Helps if you have a near by oven and supply of dough, of course, but it gives you a good 30 minutes to stop and focus on something else. I usually end up pacing around while they bake, looking out the windows, looking around the kitchen, and more oft than not have a viable solution in addition to some fresh cookies when I go back to coding.
"An infinite number of monkeys typing into GNU emacs would never make a good program."
Extremely commonplace sort of phenomenon. You work on some problem really hard, then at some point where you're not working on it, the solution comes in a flash. Happened to me last week with a mysterious bug.
Are you adequate?
I often find that the bugs that are most difficult to find are the easiest to fix. They are often some tiny corner case in one line of code that someone never thought of.
In the last product I worked on, we had a killer crash bug that different developers spent WEEKS investigating it, giving up, and then "hot potatoing" the bug to another developer. About two months later, I finally fixed the bug. A BSTR allocated using SysAllocString() should have been freed using SysFreeString(), but it was being "freed" using COM's CoTaskMemFree(). This would corrupt COM's heap causing random COM crashes in unrelated code much later!
cpeterso
Yes! This can make tweaking your overall algorithm or approach so much easier as well, if these wrapper functions are there, and well defined in their actions. You can never have *too short* a function!
VOS/Interreality project: www.interreality.org
I guess that means that there is actually a Bikeshed. Who would have figured? And I thought that it was just proverbial...
The views expressed are mine own and do not express the views of my employer.
sheesh, lighten up...
"Leo Fender was in a 'state of grace' when he designed the Stratocaster." -- Paul Reed Smith
ok