Stories
Slash Boxes
Comments
Search

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

The 25-Year-Old BSD Bug

Posted by Soulskill on Sun May 11, 2008 11:05 AM
from the better-late-than-never dept.
Bug Operating Systems BSD
sproketboy writes with news that a developer named Marc Balmer has recently fixed a bug in a bit of BSD code which is roughly 25 years old. In addition to the OSnews summary, you can read Balmer's comments and a technical description of the bug. "This code will not work as expected when seeking to the second entry of a block where the first has been deleted: seekdir() calls readdir() which happily skips the first entry (it has inode set to zero), and advance to the second entry. When the user now calls readdir() to read the directory entry to which he just seekdir()ed, he does not get the second entry but the third. Much to my surprise I not only found this problem in all other BSDs or BSD derived systems like Mac OS X, but also in very old BSD versions. I first checked 4.4BSD Lite 2, and Otto confirmed it is also in 4.2BSD. The bug has been around for roughly 25 years or more."
+ -
story

Related Stories

Firehose:The 25 Year Old BSD Bug by sproketboy (608031)
[+] BSD: 33-Year-Old Unix Bug Fixed In OpenBSD 162 comments
Ste sends along the cheery little story of Otto Moerbeek, one of the OpenBSD developers, who recently found and fixed a 33-year-old buffer overflow bug in Yacc. "But if the stack is at maximum size, this will overflow if an entry on the stack is larger than the 16 bytes leeway my malloc allows. In the case of of C++ it is 24 bytes, so a SEGV occurred. Funny thing is that I traced this back to Sixth Edition UNIX, released in 1975."
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

The 25-Year-Old BSD Bug 25 Comments More /

 Full
 Abbreviated
 Hidden
More
Loading... please wait.

  • more proof (Score:5, Funny)

    by Anonymous Coward on Sunday May 11 2008, @11:13AM (#23369210)
    ...of the superiority of Microsoft.

  • the developers probably knew about it (Score:5, Funny)

    by Anonymous Coward on Sunday May 11 2008, @11:15AM (#23369214)
    but they had more important things to do. At least until Balmer started throwing chairs.

  • See? SEE? (Score:5, Funny)

    by Frosty Piss (770223) on Sunday May 11 2008, @11:21AM (#23369274)
    See? See?

    This is the power of Open Source!

    With all those eyes looking at the code, stuff like this gets ID'd and fixed LICKITY SPLIT!

    (runs and hides)

  • Trac (Score:5, Funny)

    by extirpater (132500) on Sunday May 11 2008, @11:31AM (#23369348)
    Bug tracking software missed this because it's bug #1. lol.

  • Samba knew, but didn't pass it on? (Score:5, Insightful)

    by quarrel (194077) on Sunday May 11 2008, @11:33AM (#23369362)
    The most telling thing in TFA for me was that the bug had been identified by the Samba team and a workaround implemented for Samba.

    Surely both the samba communities and the *BSD communities are active enough that this could have been passed on for further investigation by the *BSD crowd? (Sure, samba probably would still need a workaround, particularly given the long uptimes and widespread deployment of *BSDs)

    I know nothing of the devs at Samba and *BSD, but seems a bit strange. Perhaps they did try..

    Meanwhile, congrats to Marc on fixing a bug. One of the most touted benefits of open source (whatever your license) code.

    --Q

    • Re:Samba knew, but didn't pass it on? (Score:5, Interesting)

      by id10ts (1147541) on Sunday May 11 2008, @01:16PM (#23369964)

      Yes, Samba did pass on what it found and it appears they were promptly shot down by someone on the *BSD side.

      The Samba e-mail archives contain a message from over 3 years ago [samba.org], but it doesn't give attribution to the *BSD source.

      The Samba Bugzilla also has a bug reported more recently [samba.org] involving the same issue. Reading through the bug history, you can see there was one FreeBSD dev involved in the bug discussion, and he referenced a prior conversation between Tridge (Samba) and PHK (FreeBSD) where PHK said there was no bug in FreeBSD.

  • BSD is Dying! (Score:5, Funny)

    by Doc Ruby (173196) on Sunday May 11 2008, @11:44AM (#23369420) Homepage Journal
    If you define BSD as a collection of bugs, this story proves that BSD is dying.

  • Should it be fixed? (Score:5, Insightful)

    by CaroKann (795685) on Sunday May 11 2008, @12:02PM (#23369520)
    Considering how old this bug is, and how much work-around code probably exists as a result, I wonder how many new bugs this bug fix will create.

  • Long live the Code (Score:5, Interesting)

    by GuldKalle (1065310) on Sunday May 11 2008, @01:37PM (#23370092)
    Am I the only one who thinks it's quite impressive to have 25 year old code still being used and employed on new systems?

    • Re:Wait... Would you ever hit this? (Score:5, Funny)

      by ivan256 (17499) on Sunday May 11 2008, @11:16AM (#23369230)
      Of course, now that I've R'd the FA, I understand that it's the first entry in the block (of which a directory with a sufficient number of files would have multiple), and not the first entry in the directory. Kindly ignore my previous response... Nothing to see here...

    • Re:Wait... Would you ever hit this? (Score:5, Informative)

      by TheRaven64 (641858) on Sunday May 11 2008, @11:19AM (#23369258) Homepage Journal
      The first entry in a disk block, not the first entry in a directory. Each disk block is 512 bytes, so you can store around 30 files in there with shortish file names (each stores the name, the inode and a cumulative free space counter). For large directories you have around a one in 30 chance that the deleted file will be the first one in a block. Delete a dozen files from a large directory and there's a pretty large chance you'll hit this bug.

    • Re:Many eyes make bugs shallow... (Score:5, Insightful)

      by DannyO152 (544940) on Sunday May 11 2008, @11:18AM (#23369246)
      How many "eyes" were watching BSD systems use Samba for a DOS filesystem? Seems to me, someone saw behavior and exactly because it was open source, looked into it, found the coding error and filed a bug report. It will be fixed, because everyone now knows about this, and that too is a side effect of open source, even if it's related to the politics.

    • Re:Many eyes make bugs shallow... (Score:5, Insightful)

      by garett_spencley (193892) on Sunday May 11 2008, @11:18AM (#23369252) Journal
      From the sounds of it, this was a bug that was not triggered very often. When it was finally triggered, investigated and fixed the person who found it released the info publicly, thanks to the beauty of Open Source, and everyone affected, commercial entities and FOSS users using the code alike, benefited. If this were a proprietary system that were licensed out to various companies stricken by NDAs etc. it's quite likely that if one company discovered the bug the others would never learn about it.

    • Re:Many eyes make bugs shallow... (Score:5, Informative)

      by TheRaven64 (641858) on Sunday May 11 2008, @11:23AM (#23369290) Homepage Journal

      This bug has been around for a long time, but is only visible if you have large directories and delete files from them in between calls to readdir and seekdir. This is quite uncommon behaviour, and was incredibly uncommon 25 years ago when filesystems were much smaller and directories almost never contained enough files to require more than one or two disk blocks to store the directory.

      When the Samba people found it, they decided to just code a work-around and not bother to report it to any of the BSD teams. If they had done, it would probably have been fixed in 22 years.

      Now that it has been fixed in OpenBSD, the change can easily be taken and incorporated into FreeBSD, NetBSD, DragonFlyBSD and Darwin.

        • Re:Many eyes make bugs shallow... (Score:5, Insightful)

          by Peganthyrus (713645) on Sunday May 11 2008, @11:45AM (#23369430) Homepage
          You see what you're looking for, most of the time. This sounds like a subtle bug that you're not going to find until you go looking for it; it's hard to invoke under normal usage patterns. Nobody stared at that code looking for this problem until now. But if it was closed source, the guy who fixed it wouldn't have been able to look at it and find the problem.

          A quick googling of "many eyes make all bugs shallow" brings me the more complete statement that adage is simplified from: "Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix will be obvious to someone." (Linus via ESR). Clearly this 25-year-old bug is one of the exceptions that calls for the 'almost'.

        • Re:Many eyes make bugs shallow... (Score:5, Insightful)

          by Derek Pomery (2028) on Sunday May 11 2008, @11:49AM (#23369450)
          Erm. That's not what "many eyes make bugs shallow" means.
          Well. Just reading the source is part of it, but not all.
          Fact is, if I run into odd behaviour when testing/using - if the source is available I can read it, I can breakpoint.
          I cannot do that with a binary.

          So yes. Things did occur as they were supposed to. Someone found something odd, they were able to look at code in question, and fix it.

          The shallowness is the fact that there is a direct connection between the thousands of testers/users and the code in question.
          Instant turnaround. No "user reports behaviour in detailed fashion, including testcase, to some corporate e-mail address, and maybe it eventually gets a to a developer three layers down who may be able to figure it out and fix it if he has the time"

    • Re:Many eyes make bugs shallow... (Score:5, Insightful)

      by InvisblePinkUnicorn (1126837) on Sunday May 11 2008, @11:40AM (#23369408)
      This is like saying global warming either does exist because today was the hottest on record, or does not exist because today was the coldest on record. Why are these analogous? Because in both situations, you're only considering one data point, which does not even begin to indicate a trend.
    • 3 thoughts on this:

      1. I think this bug would be classified "archeological".

      2. The question now is what happens to the Samba work-around patches. Now that the bug is fixed, do the patches cause a side-effect (i.e. "a new bug")?

      3. This gives rise to a new meme of nerd insults. "You call yourself a programmer? Why I've fixed bugs older than you!" Of course, only one man is entitled to use that line.

All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest © 1997-2009 Geeknet, Inc.