Mountain Biking Helps Squash Bugs

← Back to Stories (view on slashdot.org)

Mountain Biking Helps Squash Bugs

Posted by timothy on Sunday September 12, 2004 @06:48AM from the so-do-big-grins dept.

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

16 of 82 comments (clear)

Min score:

Reason:

Sort:

RTFB by Anonymous Coward · 2004-09-12 06:53 · Score: 5, Funny

Ride the fucking bicycle.
works for anything by Anonymous Coward · 2004-09-12 07:00 · Score: 3, Insightful

if you can't figure it out, stop trying so damn hard and just do something else.
road bike.. by MoOsEb0y · 2004-09-12 07:00 · Score: 5, Funny

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 news? by agent+dero · 2004-09-12 07:10 · Score: 4, Informative

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
1. Re:This is news? by Anonymous Coward · 2004-09-12 09:30 · Score: 4, Insightful
  
  Many of the problems I deal with, I get that Eureka moment while on the toilet.
2. Re:This is news? by c13v3rm0nk3y · 2004-09-13 01:51 · Score: 4, Funny
  
  It's not the bike riding, it's the act of "taking a break from the problem."
  
  I'll second that. I do some of my best coding in the bathtub, sans the dangerous electronics, of course.
  
  --
  -- clvrmnky
not difficult to spot at all by jeif1k · 2004-09-12 07:13 · Score: 5, Insightful

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.
1. Re:not difficult to spot at all by Homology · 2004-09-12 07:33 · Score: 4, Informative
  
  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
  As for not using C, I've read that Theo de Raadt likes the compiler and language that is used in Plan 9. Can't use it due to license problems, though.
2. Re:not difficult to spot at all by Homology · 2004-09-12 08:23 · Score: 4, Informative
  
  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.
3. Re:not difficult to spot at all by ufnoise · 2004-09-12 09:48 · Score: 3, Informative
  
  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.
4. Re:not difficult to spot at all by Xenophon+Fenderson, · 2004-09-12 11:42 · Score: 5, Insightful
  
  How is bounds checking inefficient if it protects you from nasty off-by-one errors and evil buffer overflows? Or are you one of those short-sighted programmers who believes cheap CPU clock time is more important than very expensive human time (i.e. time wasted dealing with crappy programming languages and debugging stupid bounds problems, or worse, money lost because a critical bit of information was destroyed, altered, or disclosed due to a buffer overflow vulnerability)?
  
  And yes, those were both rhetorical questions. I am sick and tired of crappy, bug-ridden software that doesn't do proper input and bounds checking. As far as I'm concerned, it's the programmers fault, either because she didn't write the bounds checks in manually or because he's not using a modern programming language (where "modern" == "not a glorified assembler"). You all aren't Mel, who can write practically perfect programs while sleepwalking, so don't give me a load of crap about how bloated your program would be if it was actually written properly. As a computer security guy, I am sick and tired of cleaning up after the exploits you all apparently work so hard to code into your software.
  
  </rant>
  
  --
  I'm proud of my Northern Tibetian Heritage
5. Re:not difficult to spot at all by tedu · 2004-09-12 18:37 · Score: 4, Insightful
  
  have you used purify/valgrind? as far as "avoiding the inefficiency of array bounds checking on each access" they pretty much suck. performance is nowhere close to what could be considered "production" level.
6. Re:not difficult to spot at all by tedu · 2004-09-12 18:40 · Score: 4, Insightful
  
  no amount of "error checking" would have helped. this wasn't a buffer overflow off by one. it was ref count.
  
  yeah, garbage collection would help, but C with GC is not a "systems programming language with error checking".
taking a crap by endx7 · 2004-09-12 09:08 · Score: 4, Funny

Hmm. Well, I did figure out how I wanted to implement a portion of my code when I was taking a crap recently.
1. Re:taking a crap by r_j_howell · 2004-09-13 01:42 · Score: 4, Funny
  
  I had a good friend at school remark to me that ALL his best programming ideas came to him in the bathroom. Mine generaly don't. But you couldn't tell that from looking at some of the stuff I've churned out.
Bake Cookies! by maskedbishounen · 2004-09-12 12:11 · Score: 4, Interesting

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