Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Bug Operating Systems Programming BSD IT Technology

Mountain Biking Helps Squash Bugs 82

Posted by timothy 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."
This discussion has been archived. No new comments can be posted.

Mountain Biking Helps Squash Bugs More

Mountain Biking Helps Squash Bugs

Comments Filter:

  • RTFB (Score:5, Funny)

    by Anonymous Coward on Sunday September 12, 2004 @02:53PM (#10228753)
    Ride the fucking bicycle.

  • works for anything (Score:3, Insightful)

    by Anonymous Coward on Sunday September 12, 2004 @03:00PM (#10228791)
    if you can't figure it out, stop trying so damn hard and just do something else.

  • road bike.. (Score:5, Funny)

    by MoOsEb0y ( 2177 ) on Sunday September 12, 2004 @03:00PM (#10228794)
    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!
    • wider tires would allow one to run over more ants. Oh, the dillemmas! And running over ANT is good? I thought it was all about the Bugs.

  • This is news? (Score:5, Informative)

    by agent dero ( 680753 ) on Sunday September 12, 2004 @03:10PM (#10228844) Homepage
    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:This is news? (Score:1, Flamebait)

      by ezzzD55J ( 697465 )
      Indeed.. Experts? Show us how it's done? The guy may very well be a guru, but this story isn't evidence of it.. Although it's always easy to comment from the sidelines (and with 20/20 hindsight), the guy says it himself:

      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). Not that this is really news, but ver

    • Re:This is news? (Score:4, Insightful)

      by Anonymous Coward on Sunday September 12, 2004 @05:30PM (#10229576)
      Many of the problems I deal with, I get that Eureka moment while on the toilet.
    • I find that I have to get much further from the problem, in fact it happens to me so often that I hike with an ultra-portable, just in case.

    • Re:This is news? (Score:5, Funny)

      by c13v3rm0nk3y ( 189767 ) on Monday September 13, 2004 @09:51AM (#10234932) Homepage

      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.

  • not difficult to spot at all (Score:5, Insightful)

    by jeif1k ( 809151 ) on Sunday September 12, 2004 @03:13PM (#10228862)
    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.

    • Re:not difficult to spot at all (Score:5, Informative)

      by Homology ( 639438 ) on Sunday September 12, 2004 @03:33PM (#10228958)
      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.

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

        You mean Alef? I don't think there are licensing problems with the language, and writing a compiler for it wouldn't be hard. I'm not convinced, though, that Alef is a good systems programming language.

        But safer systems programming languages are a dime a dozen, people just have to use them.
    • 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 acce

      • Re:not difficult to spot at all (Score:5, Insightful)

        by Xenophon Fenderson, ( 1469 ) <xenophon+slashdot@irtnog.org> on Sunday September 12, 2004 @07:42PM (#10230814) Homepage

        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>

        • You are right. It is the programmer's fault. But it is also the programmer's fault if the program is so inefficient, it is useless. You would then be complaining about how slow the program is, rather than about the exploit. I don't know who Mel is, but I assume he has debugging tools which would allow him to diagnose the errors found in this article. In addition, there is no reason array bounds checking could not be performed in debug versions of the code, but left out of the final optimized version.

      • Re:not difficult to spot at all (Score:4, Insightful)

        by tedu ( 647286 ) on Monday September 13, 2004 @02:37AM (#10233034)
        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.
        • 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.
        • 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.

          This is only because the C runtime does not help in this regard. This can be done very efficiently in other environments.

      • There are debugging tools out there which reliably find these bugs in C/C++ and FORTRAN.

        No, they don't find them "reliably", they only find them if you happen to have a test case that triggers the bug and you run the software under valgrind or purify when you execute the test case. For security problems arising from buffer overflows, the probably is usually that developers don't even think of the case.

        Tools such as these help to find problems, while avoiding the inefficiency of array bounds checking on
        • Yes, if you use C++ with a decent class library and good programmers, you get good runtime safety. The problem with C++ is that if you have a large project with lots of ex-C programmers, they sneak in unsafe code everywhere and usually don't even understand that they are doing so.

          Nevertheless, it would probably be a big step forward if Linux and BSD allowed C++ code in the kernel.
    • 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.
      • The biggest problem I have with the STL is that many debuggers don't have nice support for it. Thus, it's very difficult to observe what's stored in that nice vector or tree, when you hit the breakpoint. A few newer ones are adding automatic display of STL structures, which will be very nice, but for now, I'm stuck with VC++6, which is horrendous WRT these kinds of data structures.

        I'd certainly welcome any ideas people have on how they actually debug code using the STL.

    • Re:not difficult to spot at all (Score:4, Insightful)

      by tedu ( 647286 ) on Monday September 13, 2004 @02:40AM (#10233049)
      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".
      • Same problem: C is a language that makes it difficult to write correct code, for numerous reasons.

        A systems programming language with error checking needs to handle both automatic storage management and array bounds checking (plus a few other compile-time and runtime tests that are missing from C). Users should also be able to turn off either/both selectively and explicitly.
    • ... 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.

      I don't think you understand the "low-level" appeal of C, error checking and other useful security features like strong typing are not low-level. The ability to break abstractio

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

      The best check for such errors is other eyeballs.

      It's not the language. It's development procedures. Code reviews will catch these things, and other bugs besides (as well as making people write neater, more easily understandable code, and giving coders and opportunity to learn from each other), but reviews take development time - never mind all the time they save in deb

    • ...would have found this immediately.

      use it [nl.net].

  • Not new... (Score:3, Insightful)

    by HawkingMattress ( 588824 ) on Sunday September 12, 2004 @03:23PM (#10228912)
    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...
    • I guess everyone has it's own way of taking... fresh air. Depending on the time of the day, I do different things.

      If it's the second half of the afternoon,
      I just go back home.

      During the evening,
      Off for a beer.

      Any other moment,
      Walk, coffee or walk to coffee...

      And yes, it does work. I usually find my bugs within 10 minutes after sitting back to my desk, which obviously includes reading slashdot.
    • Very well, I order you to relax!
    • Another thing that helps is explaining the problem to someone else. It also makes you look at the bug from another point of view, and very often you find the solution without the other person even saying a word.
    • ...and having sex works well - if you can get it, that is.
    • Something that I have found to be very, very useful is describing the problem to somebody else. Just having to reorder your thoughts about the issue in order to get the message across puts everything in a different light. Plus, you consider things that your brain usually just skips over without a second thought. I can't count how many times I've been telling a coworker about a problem and halfway through the explanation it hits me ("Well, then when we're iterating through the list the code... Oh, crap,
    • Usually, if I'm working on a problem late at night, I find it more productive to just go to sleep. You wouldn't believe the number of times I've woken up in the morning with the solution being blindingly obvious to me.
      • Yes me too. The only problem is that even if i know this, usually when i'm coding at night i'm "zoning", in a state which pushes me to go on. So i'll search a solution for several hours generally for nothing, and i'll discover in the morning that I was doing stupid obscure things while the solution was indeed obvious...
        I'm now trying to restrain myself from doing this, as sometimes you can furthermore do stupid things which will cause you to spend even more time later on, solving problems which should hav

  • taking a crap (Score:5, Funny)

    by endx7 ( 706884 ) on Sunday September 12, 2004 @05:08PM (#10229421) Homepage Journal
    Hmm. Well, I did figure out how I wanted to implement a portion of my code when I was taking a crap recently.

  • *yawn* (Score:2, Insightful)

    by Estanislao Martínez ( 203477 )
    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.
  • It turns out they were both off-by-one errors that were easy to fix but notoriously difficult to spot

    I was wondering if this is the kind of thing that most likely would ahve been avoided in a more "modern" language, like pointer arithmetic problems could be avoided by not using C? Not a trool -really- I was just wondering. I RTFA but can't tell from reading it...

    • Re:Would a more modern language madea difference? (Score:1, Insightful)

      by Anonymous Coward
      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.
    • 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'
    • Off-by-one errors are possible in almost every language. Wherever there is some kind of list or set of objects, however expressed, there is the potential for such an error. The actual implementation language doesn't matter here.
    • System programming is done with C because it is a pretty lcean abstraction away from the hardware. Assembly is the cleanest, but C maps pretty well onto assembly that maps pretty well onto what the processor actaully implements.

      This is important because the programmer has some idea of what the program is actaully doing, and a good programmer has a great idea of what the program is actually doing.

      Anything that is pretty close to the hardware should be done in C or soemthing similar. Computers have been f

  • hard-to-find bugs are often the easiest to fix (Score:3, Interesting)

    by cpeterso ( 19082 ) on Monday September 13, 2004 @02:11AM (#10232908) Homepage

    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! :(
  • The tools are there, why not use them. Or just use java.

  • Yes! (Score:3, Informative)

    by agentk ( 74906 ) on Monday September 13, 2004 @09:53AM (#10234962)
    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!

  • The most productive breaks for me are those that force oxygenated blood to my brain, e.g. running, hiking, biking, etc. Of those, the best are the ones that don't require concentration but allow the mind to wander freely.

  • Hummm.... (Score:3, Funny)

    by utlemming ( 654269 ) on Tuesday September 14, 2004 @02:14AM (#10243760) Homepage
    I guess that means that there is actually a Bikeshed. Who would have figured? And I thought that it was just proverbial...
  • I beleive that the hackers dictionary calls these Obi Wan Errors.

Slashdot Top Deals

"Protozoa are small, and bacteria are small, but viruses are smaller than the both put together."

Close