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

11 of 82 comments (clear)

  1. works for anything by Anonymous Coward · · Score: 3, Insightful

    if you can't figure it out, stop trying so damn hard and just do something else.

  2. not difficult to spot at all by jeif1k · · 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 Xenophon+Fenderson, · · 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
    2. Re:not difficult to spot at all by tedu · · 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.

    3. Re:not difficult to spot at all by tedu · · 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".

  3. Not new... by HawkingMattress · · Score: 2, Insightful

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

  4. Re:This is news? by Anonymous Coward · · Score: 4, Insightful

    Many of the problems I deal with, I get that Eureka moment while on the toilet.

  5. *yawn* by Estanislao+Mart�nez · · Score: 2, Insightful

    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.

  6. Re:Would a more modern language madea difference? by Anonymous Coward · · Score: 1, Insightful

    It was not a "pointer arithmetic" problem, it was a counter problem. You don't even need a computer for that to happen, try counting the runners passing the finish line at a marathon... Miss one, and you'll be waiting forever for the last guy to come in.

  7. Re:Would a more modern language madea difference? by NickHolland · · Score: 1, Insightful

    Curiously, the people who know OSs the best have been sticking with C. The people talking about "modern languages" have been mostly doing just that: talking. The fact that nothing has been done beyond "talk" says more then all the talk.

    Someone who believes this can be done has to prove it by reimplementing an existing OS in one of these "modern languages", and demonstrate that it is maintainable, performs sufficiently, and actually works better than a C implemented OS. Implementing a "whole new" OS isn't going to work, as the barriers to entry in this business are just too high -- you would have to implement an entire software library as well. And note: having to have a multi-processor P4 or AMD64 to do what is currently done with a Pentium 90 isn't going to fly...

    I really doubt any programming language can make programing "intrinsically safe". In fact, if past experience is any guide, it would probably lower the bar to entry into OS programming, and probably end up with a net REDUCTION in quality. All it takes to prove me wrong is ...well, do it. :)

  8. Re:really stupid by BillyBurrito · · Score: 2, Insightful

    ok