パスワードを忘れた？ アカウント作成
Close
30041 story

さらに太古のバグが見つかる 65

ストーリー by Acanthopanax
1匹みつけたら 部門より

sempreff 曰く、

seekdir のバグ は 25歳だったらしいが、もっと古い奴が他にも隠れているかもしれない。実際、最近発見された yacc のバグ は 33歳と言われている。

今回の虫発見のきっかけが新実装の malloc のテストで、再現環境は sparc64 のみ、というのが興味深い。発見者の otto 氏は最終的に 6th edition まで遡って調べている。そういう根性はとっても大事だと思う。そうやって調べたから虫の推定年齢がわかったわけだし。

コード検査の手法や技術は充分成熟していると思っていたが、まだ発展の余地があるのだろう。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

さらに太古のバグが見つかる More

  • バグの年齢とは？ (スコア:5, 興味深い)

    by Futaro (2025) on 2008年07月13日 7時34分 (#1382211) ホームページ 日記
    そのバグが長く放置されてきた、ということは、以下のいくつかの理由がある、と思われる。

    １．良く使われるプログラムだが、全体にたいした影響がない部分だった。
    ２．あまり多く使われないプログラムだった。
    ３．そもそもメインテナーがいなかった。

    まぁ、他にも理由はあるでしょうが、「１．」はかなり多いのではないかと。

    つまり、放置しておいても問題ない、というレベルのものであったとすると、この「バグとり」の作業は、効率が悪い作業、ということにはならないか？
    • OpenBSD の宣伝のために蛇足で補足しまーす。

      今回の件はたいして影響のないものでしたが、
      そういう、かつて問題なかった部分が
      64 ビットのときとかメモリが大きいときとか
      新たに問題になる場面が増えてるわけですよね。

      すると心理的にも (「だってずっと大丈夫だったもん」)
      技術的にも(「再現しません。そのメモリ安物じゃね？」)
      見付けにくいので、部門名のとおり
      バグのパターンで叩いたり、デバグ技術の進歩で潰したり
      する必要が出てきます。事前に。

      今回の大切な点は、OpenBSD "otto" malloc の意地の悪さ
      (パフォーマンス重視のシステムでは考えられない実装かも)
      によって実際にバグが取れた (しかも 33 年間も
      気付かれていなかったものが) という点であり、
      それが影響の大きいものかどうかではないと思います。

      まさしく proactive security の問題なのです。

      シェア
      親コメント

    • Re:バグの年齢とは？ (スコア:5, すばらしい洞察)

      by Anonymous Coward on 2008年07月13日 14時35分 (#1382337)
      4. みんなそういう仕様だと思っていた。
      シェア
      親コメント

    • Re:バグの年齢とは？ (スコア:4, 興味深い)

      by WindVoice (14680) on 2008年07月13日 8時53分 (#1382229) 日記
      SPARC64は64bit環境としては古いものですけど、それでも33歳にはならないですから、そもそも起こらないバグだった時期が長いのではないかと。SPARCv9から64bitで動作する [wikipedia.org]ので、1995年から発生の可能性があったバグということでしょうか。
      --
      人生は七転び八起き、一日は早寝早起き
      シェア
      親コメント

    • Re:バグの年齢とは？ (スコア:3, すばらしい洞察)

      by Anonymous Coward on 2008年07月13日 8時28分 (#1382222)
      基本的にバグ取りは効率悪い作業ですよ。
      だって、自分のところでちゃんと動いていればそれで十分って人がほとんどなんだから。
      だからこそ「目玉を増やす」ことは重要なんですよ。
      シェア
      親コメント

      • Re: (スコア:0)

        by Anonymous Coward
        >「目玉を増やす」ことは重要

        つまり「テスト担当者が一人だけ」なんてな企業は一番危険だと。

        で、テスト担当者を増やせというよりは、
        「ドッグフードを食え」のほうが
        どう考えても人数を多く確保できるので、お勧めです。
        特に小さい企業ではね。

        ＃MSも馬鹿にならんな。

  • 僕の頭髪にも太古のバグが発見されそうです (スコア:5, おもしろおかしい)

    by Anonymous Coward on 2008年07月13日 7時56分 (#1382213)
    製造されて三十余年になる僕の基幹システムですが、他者との接続に関する不具合において
    単なる相性問題ではなく頭部のバグによるものであることがこのたび初めて発覚しました。
    前バージョンにも同種のバグがあるにも関わらず、俺一同それを見ないフリをしていた
    のが発見が遅れた大きな要因とみられます。
    パッチを当てる費用が無いため、当面はバーコードシステムの導入でしのぐ予定です。

    なお、腹部にもバグがあるようですが、これは太古のバグと言うより太鼓のバグ
    …ってやかましいわ

  • やっく☆でかるちゃー (スコア:5, 興味深い)

    by Anonymous Coward on 2008年07月13日 10時07分 (#1382248)
    > The bug was only triggered on sparc64, since it uses 8k pages.
    > The default yacc stack size for C++ is 24 * 200 = 4800 bytes,
    > which is larger than a page on most platforms.
    > In this case malloc returns a page aligned object,
    > no moving of the allocation inside a page occurs.

    sparc64の8kページで起こるバグって言ってるけど、ようするに
    デフォルトスタックより大きいページだと発生するみたいですね。

    現実の環境が、開発時に想定出来た範囲を超えたから表面化したバグってとこですか。
    ってことは、今後もソフト屋の想像力を超えたハードの成長で
    表面化するバグが現そうですね。

    # 「最古のバグ」はまだ更新の余地がありそうですね。

    もっとも、yaccみたいに古くから良く使われるツールでないと表面化しなさそうですが。
    • bisonのソースにも同じようなとこがあるんですが大丈夫なんですかね。
      --
      love && peace && free_software
      t-nissie
      シェア
      親コメント
    • > The bug was only triggered on sparc64, since it uses 8k pages.
      sparc64でしか起こらないバグ、と言うことは単にyaccがsparc64で動作させることを
      想定していなかっただけじゃないのかな？
      と言うか、yaccが作られた時にsparc64がありましたっけ？＜あまり歴史知らない

      作成時に存在しないアーキテクチャに対しても対応しないとバグと言われるなら、
      全てのプログラムが将来バグを含むと思うけど。

      ＃元々sparc64上の動作を想定して作成されて、かつ問題が発生したなら
      ＃バグとは思うが。。。
      シェア
      親コメント

      • Re:これってバグと言うのか？ (スコア:5, 参考になる)

        by Anonymous Coward on 2008年07月13日 21時41分 (#1382413)
        > sparc64でしか起こらないバグ、と言うことは単にyaccがsparc64で動作させることを
        > 想定していなかっただけじゃないのかな？
        > と言うか、yaccが作られた時にsparc64がありましたっけ？＜あまり歴史知らない

        ちゃいます。アロケートしたメモリの外側をアクセスしているので、言語仕様に照らしてもバグと言いきれるでしょう。
        たまたま、小さなページサイズのアロケーションでは (そして既存のアロケータの多くでは)
        アロケートした領域の後ろに余裕があったので不正なアクセスに誰も気づかなかったというだけです。

        なので

        > 作成時に存在しないアーキテクチャに対しても対応しないとバグと言われるなら、
        > 全てのプログラムが将来バグを含むと思うけど。

        そういう話ではないのですよ。

        でもvalgrindとかpurifyみたいなメモリチェックツールでは今まで見つからなかったのかなあ?
        シェア
        親コメント

  • 太古のバグといえば (スコア:3, おもしろおかしい)

    by Anonymous Coward on 2008年07月13日 11時48分 (#1382298)
    自分が中学生の頃、「太古の馬具発見」というニュースがあって、それを聞いてぎょっとした覚えがあるな。
    すでに四半世紀も昔の話だ。
  • >　コード検査の手法や技術は充分成熟していると思っていたが、まだ発展の余地があるのだろう。

    いやいや。そういう問題じゃなくて。近代的なコード検査手法の出現以前に書かれたツールで、チェックを受けないまま昔から使いづけられてきた・・というだけでは？

    • コード検査技術の問題ぁ？ (スコア:1)

      久々に名古屋弁を目にして懐かしい気分になりました。

      シェア
      親コメント

    • Re: (スコア:0)

      by Anonymous Coward
      「近代的なコード検査手法」って何？　ぜひ教えてください！
      • lintとかprofが古典的ツール。それより新しいのは全部近代的ツール。という基準 じゃだめかな？
        シェア
        親コメント
        • コンパイラがエラーを出したらチェック、アプリ全体に適当なテストデータを入れてチェック、lintなどの小粒のツールの出力を目視でチェック、ソースコードを目視デバッグ・・・あたりはおおむね古典的手法といっていいんじゃないでしょうか。

          タレこみ者がどう思ってたのかは知りませんが、コード検査の手法や技術というと、いまどきのツールを使うとか、全体じゃなくてモジュール単位で先に検証しておくとか、テストケースの妥当性も検証する（のにはやはりカバレッジツールを使う）とか言ったあたりでは？ mallocデバッガを使ってみるのは近代的（v7や32Vの時点ではなかった手法だから:-)　。

          #1382244　で言いたかったのは、これは、「現代のコード検査の手法や技術で調べていたのにもかかわらず、見逃されていたバグがあった」という事例ではないよねってこと。

          シェア
          親コメント

        • Re: (スコア:0)

          by Anonymous Coward
          きかれてるのはツールではなく、手法…

          という、つっこみはなしの方向で？

      • Re: (スコア:0)

        by Anonymous Coward
        人海戦術．
  • ITの世界において古代や中世、近代って何時ごろなんだろう。
  • 本当に年代物だと
    残したくなるよね。
    古代バグ保護運動に参加しませんか？

  • アッテンボローさんがよく言ってたじゃない (スコア:0)

    by Anonymous Coward on 2008年07月13日 10時35分 (#1382262)
    「伊達と酔狂」だ！って、、、じゃなくて「それがどうした？」

    バグれぽに対しても「だから、それがどうーした？バグではない、仕様だ」
    もうこうなれば糞です。
typodupeerror

UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア