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."

This is news?

[agent dero]

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.

Re:not difficult to spot at all

[Homology]

The OpenBSD developers does not fool themselves into thinking that they don't make mistakes. Several of the techniques they use, like privilege revocation and privilege separation is to lessen the impact of programming mistakes, including their own. Theo de Raadt recently gave a talk on Exploit Mitigation Techniques [openbsd.org]

As for not using C, I've read that Theo de Raadt likes the compiler and language that is used in Plan 9 [bell-labs.com]. Can't use it due to license problems, though.

Re:not difficult to spot at all

[Homology]

Most likely the C-dialect compiler that Plan 9 uses. But the AT&T license is too restrictive for Plan 9 code to be imported into BSD, as far as I know.

Re:not difficult to spot at all

[ufnoise]

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.

There are debugging tools out there which reliably find these bugs in C/C++ and FORTRAN. For example:
purify (not free)
valgrind (free)

Tools such as these help to find problems, while avoiding the inefficiency of array bounds checking on each access.

Re:not difficult to spot at all

[Profound]

You can use use C++ STL vectors with at() when you want bounds checking or use a direct index when you don't. Thus you can keep the backwards compatability with C and have the choice of sacrificing safety for speed when you need it.

Re:not difficult to spot at all

[setagllib]

Mel: http://www.catb.org/jargon/html/story-of-mel.html

No debugging tools there, if any tools at all.

Re:not difficult to spot at all

[ufnoise]

Yes I have. I only use them when I am debugging. Then I don't need to implement array bounds checking on the "production" version of the code.

Yes!

[agentk]

First, when maintaining counters for list/queue/... entries, don't fuck with either the counter or the list directly anywhere; use wrapper functions that take care for both (not using a counter/list pair is not an option in many, including these two, cases).

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!