ほぼすべてのBSDに存在してきたseekdir()のバグが25歳で死す 70
ストーリー by Acanthopanax
四半世紀 部門より
四半世紀 部門より
tamoの日記 曰く、
OpenBSD の Marc Balmer による When seekdir() Won't Seek to the Right Positionというブログエントリによると、4.2BSD 以来すべての BSD libc (Mac OS X も含む) には、unlink() のタイミングなど特定の条件下でseekdir() が不正な値を返すバグがあり、Open/Net/Free/Dragonfly BSD で修正されました。(Undeadly の同名記事には各 BSD の修正箇所も載っています。)
発見と修正のきっかけは Samba ユーザからの苦情で、じっさい Samba 開発者たちは以前から BSD の *dir() にバグがあることを知っていたようです。とはいえ、Marc もこれほど単純なバグが約 25 年も生き残っていたことに驚きと遺憾の意を表明しています。
バグ探し、という感情労働 (スコア:5, 興味深い)
Re:バグ探し、という感情労働 (スコア:3, 興味深い)
「くらえ！」と逆転裁判風にコード突きつけても「お前の方が間違ってる」という人が時々いるのには参ります。
署名スパムがウザい？アカウント作って非表示に設定すればスッキリさ。
Re:バグ探し、という感情労働 (スコア:5, おもしろおかしい)
(1)そんな事実はない→テストをした結果なのですが
(2)私のせいではない→プログラムを作成したのはあなたです
(3)テストの方法が悪い→指示された通りにテストしています
(4)分かっているならお前が直せ→役割分担を破ると、プロジェクトが成り立ちません
(5)今夜は闇夜ですよ→私を殺してもバグはなくなりません
といったところでしょうか。
Re:バグ探し、という感情労働 (スコア:2, 興味深い)
この抗弁は結構正当な主張であることが多いのでは。 考えられるシナリオ:
# ええ、確かに前任社の遺した負の遺産と付き合っていますとも。
Re:バグ探し、という感情労働 (スコア:2, 興味深い)
実話なのでAC
プロダクツは子供のようなモノだからね (スコア:2, 興味深い)
そういった実体験はないのですが、
自分のプログラムが各所で活躍しているという報告を受けると
自分の子供を誇らしく思うような感情が湧くので、
そこから類推しました。
Re:プロダクツは子供のようなモノだからね (スコア:2, おもしろおかしい)
＃子孫繁栄は任せたぞ弟たちよ
Re: (スコア:0)
甘く育てるも厳しく育てるもどっちも有り得る(親次第だ)ってことですね。
わかります。
＃じゃあ子供のようなものであろうが無かろうが同じようなもんじゃないの？とも思う。
図式 (スコア:5, おもしろおかしい)
オフトピ (スコア:3, 興味深い)
と言われたので調べてみたら、自分が生まれた年に書かれたコードだったなぁ。
（商用OSですが、幸か不幸かソースを見れる環境にいたので）
ちなみに問題の原因は、コードが書かれた当時には恐らく想像もされなかったであろう数のリモート接続が
日常的に行われていて、コマンドが処理できる接続数の上限をギリギリ超えていたというものでした。
想定が甘いと言ってしまえばそうですが、20数年先を見越したコードってのもなかなか書けるもんじゃないよなぁ、
と妙に色々と考えてしまいました。
そもそも、10年単位で使われるコードを書く機会なんて多分そんなにあるもんじゃないでしょうし。
ましてや今自分が書いてるコードが今生まれた赤ん坊に修正される運命にあるなんて・・
結果的だけ見れば、20数年経ってようやく修正されたバグの1つかなと思います。
（バグとして処理する必要が出てきたのは極最近なんでしょうけど）
私はコードの読み書きが本職ではないですが、本職の皆さんはこんな経験ザラですか？
Re:オフトピ (スコア:2, すばらしい洞察)
>と妙に色々と考えてしまいました。
それが世界的な規模で問題になっちゃったのが西暦2000年問題ってヤツでして。
当時の事情からすれば、ある意味仕方が無かったりする場合もあるとは思いますよ。
#その問題を解決しなきゃいけない世代の人は大変なんですけどね
Re:オフトピ (スコア:1)
Windows 98が出た頃書いたプログラムをまだ愛用しています。
今年の9月で10年になりますから10年くらいだったら割と使われてるんじゃないでしょうか。
バグ報告大好き (スコア:3, 興味深い)
自分が作ったコード(仕事とか趣味とか)で bug reportもらうとかなり喜んでしまうのって。
なんてーかそんだけ本気で使っていただけてるってのは嬉しいんですよね。
仕事なんか自分から率先して(できれば公開)BTS鯖を用意するようにリクエストしてしまう & そういうの禁止されると凹むぐらいで。
別段マゾだとは思わないんだけど、ソフトウェアが仕様どおりに動いて喜ばれることもあまりなく、かといってワザと bugつっこむほどヒネてもいないので、普通にバグ発見してくれて「自分の知らなかった/気付かなかったことを教えてくれること」ってのは結構うれしいのですよ。
…やっぱマイナーなんかな、こういうのって。
Re:バグ報告大好き (スコア:1)
放置するって意味ではなくて (スコア:1)
当然、バグが完全にないものを出力できていればいいのですが、
残念ながらそれを証明するコストは厳しいものがあります。
また、バグを出さないようにするのは当然です。
「適当につくった後、誰かに相手してほしくてバグ報告を待つ」という意味での
報告がうれしいということでもありません。
バグをどれだけ減らそうとしても 0にはできないとするなら、その発生した
場合にどう振る舞うかが大切だと考えます。
そこで、バグが発生した時に報告してもらえることの価値を私は評価したいのです。
発生/発見したときに、報告したら修正されるだろう、修正しろという意図があると思います。
その要求が作った側に届くことはとても嬉しいことだと思います。
結果、自分の想定しなかった知識を得てより品質をあげることができますし、そのバグが
何故残ったのか&実装されたのかを検証することで他のバグを発見したり予防できたりします。
結果、信頼性と品質をあげるコストがより低下していきます。(「バグがバレたので
とりあえず修正だけする」の繰り返しではダメですが)
例え発表/発売後であっても、短期的にはバグの報告があがることで上司やクライアントの
不興を被ることもあるかもしれませんが、ユーザー(or関係者)が見つけた問題点を汲みとれる
システムがあり、それを活用してもらえることはやはり嬉しいことです。
# 当然、その報告が原因で自分が失職しても、それは自己責任であり
# 高い授業料を払って良い勉強をしたと考えています(経験あり(笑))
私のガキのころに (スコア:2)
バグ(享年25歳)の冥福を皆で祈りましょう。合掌。
# 自分ときたら1ヶ月放置したコードですら難読なのに…。
# 25年前に書かれたという事実を追えるのもある意味スゴイけど。
---- ばくさん！＠一応IT土方
Re:私のガキのころに (スコア:3, 興味深い)
> # 25年前に書かれたという事実を追えるのもある意味スゴイけど。
某ドライブのファームに 6年ぐらい関わってましたが、
2年越し、3年越しのバグちょぼちょぼありました。
まあ実際に即不具合になるものではなく、極端な条件下でのみ
問題になる可能性があるとか、結果的に全く問題がないが
開発者の頭の中のイメージとぜんぜん違った動きをするコードに
なってた、などですが。
変更履歴を追いかけて、誰がどういう状況でエンバグしたかを
追いかけると、だいたい自分でへこみました。
ソフト屋さんって、やっぱりみなさんMっけ多いですか？
そういう自分の恥を記録する意味でもソース管理は重要です。
仕様です (スコア:1, おもしろおかしい)
というようなもんですかね。
Re:仕様です (スコア:2, すばらしい洞察)
もっと長命な (スコア:1, 興味深い)
まだ発見されたことが無いのでしょうか？
25年という数字が大きいのか小さいのかよく判らなかったもんで。
＃すべてのバグを数年塩漬けに"されてしまった"プロジェクトに居たことがあるのでAC
＃あとで修正しにくいったらありゃしない。当時の詳細なコンテキストなんてみんな覚えてないからね。
Re:もっと長命な (スコア:2, おもしろおかしい)
Re:もっと長命な (スコア:4, おもしろおかしい)
しかも人間は図体が大きく、維持費が高くつき、管理しにくく、おまけに環境を汚染する。
このような装置が製造され配備され続けているのは驚くべきことだ。
しかし、人間はいたるところで幅をきかせているので、われわれがプロトコルを設計して彼らの限界を克服しなければならない。
--Kaufman
なかなか面白いと思った罵倒。
Re:もっと長命な (スコア:1, 参考になる)
Re:もっと長命な (スコア:4, おもしろおかしい)
そういわれた人もいるらしいですよ。酷いですね。
Re: (スコア:0)
と言われたかったのですね。
ええ、わかります。
Re:もっと長命な (スコア:2, おもしろおかしい)
Re:もっと長命な (スコア:2, すばらしい洞察)
Re:もっと長命な (スコア:3, 参考になる)
に書いておかないと。
免責事項に「2038年以降は動作しません。」と
ホントに書いてあったりして…
Re:もっと長命な (スコア:3, 興味深い)
それはさておき、一般PCはともかく、25年経ったら2038年問題はプラント制御系で笑えない状況になってるほうに１００円。
# 30年前に納めたモノがまだ動いてますからのぅ‥
Re: (スコア:0)
>に書いておかないと。
ソースコードがマニュアルです
Re: (スコア:0)
Re:もっと長命な (スコア:1)
署名スパムがウザい？アカウント作って非表示に設定すればスッキリさ。
Re:もっと長命な (スコア:1)
本当に？
まじめな話、最初に符号付32ビット整数になってから最初に符号付64ビット整数になるまで、25年も掛かったっけ？
Re:もっと長命な (スコア:1, 参考になる)
Ken Thompsonの言ってた「もしUNIXを作り直せるなら、creat()をcreate()にしたい」は実現したわけだ
デーモンくんのアイコンが… (スコア:0)
Re: (スコア:0)
なんだよ死すって (スコア:0)
「２５年で駆除される」等の方がよろしくありませんでしょうか
本題に戻ると大きなシステムでは意外と単純なバグの方が
長期間放置される傾向にあるような気がするのですがどうでしょう
Re:なんだよ死すって (スコア:1, 興味深い)
引用部分を改変せずにどう補足するかが編集者の腕の見せ所なのかな。
それより、"sorry"を「遺憾 [nhk.or.jp]」と訳してあるのに違和感が…
Re:なんだよ死すって (スコア:1)
明確にsorryなら確かに違うと思う
Re:なんだよ死すって (スコア:1, おもしろおかしい)
Re: (スコア:0)
Re: (スコア:0)
元コメも本文は丁寧なのに、このサブジェクトだけ見るとけんか腰にも見て取れる。
書く時にサブジェクトを気にするのには高等な技術かある種の力が必要なのだろうね。
Re:なんだよ死すって (スコア:1)
思いたい人は勝手に思っていればいいんだけども…。
あなたはバグの駆除を死と呼んではいけないと何故思うのかな？
PCが壊れたりするのも死ぬって言うけど、それはOKなのか。
普通に強制終了を殺すって言ったりもするよ。
結局のところ、言い回しが自分の好みに合うかどうかで判断してるでしょ。
で、気に入らない言い回しを見つけたら、まるで相手が悪いかのように言う。
でも実際には、「こう言わなきゃいけない」っていうルールがあるような事じゃないね。
それを自分の好みで自分勝手に非難するのは、あまり褒められた行動ではないな。
----- 傷の治療は傷より痛い -----
Re: (スコア:0)
なんについて突っ込みが必要なんだい？
> 元コメも本文は丁寧なのに、このサブジェクトだけ見るとけんか腰にも見て取れる。
君は、この短い単語からよくけんか腰ってわかるね。
単に君が悪意を持って読んでいるからじゃないのかい？
> 書く時にサブジェクトを気にするのには高等な技術かある種の力が必要なのだろうね。
わけのわからん事をいって、自分を正当化しようとするなよ。
…とか言われたらやだろ？
どうでもいいことをあげつらうのはやめようぜ。
Re:なんだよ死すって (スコア:1, おもしろおかしい)
「歳」って漢字はもともと「年」と同じ意味の古い文字なのに、なぜか年齢を表す場合のみに残った。
さらに省略して「才」を使う場合も多いけど、これも…
…なんて、言い出したらきりがないし意味もない。
そういうのをウザいって言うんです。
Re:なんだよ死すって (スコア:1)
教訓 (スコア:0)
このクラスの人ですらこうなのだから、
「こっちはこれまで動いてきた（だから正しい）」
という前に指摘は一度はきちっと考えろってことか。
Re:教訓 (スコア:3, 興味深い)
問題は, スタージョンの法則ではないけど「全ての指摘の9割は的外れ」ってことですね. 少人数でそれなりのレベルの人たちの間では指摘は有益ですけど, 不特定多数が相手となるととたんにレベルが落ちますから. こうなると, いかに話を聞かないかってことが開発効率向上にもつながるってもんで.
本当はメーリングリストあたりがこうしたクズ指摘のフィルタになればいいんでしょうけど.
Re:教訓 (スコア:2, 参考になる)
一介のアプリ屋風情がOSのバグ指摘などちゃんちゃら可笑しいわ！と
笑い捨てるわけにもいかず、結果としてバグを葬ることができたと。
とはいえアプリ屋は
OSがおかしい→おかしいのはお前のアプリ
コンパイラがおかしい→おかしいのはお前の期待
データベースが（略→おかしいのはお前の頭
ハードウェアが（略→データシートくらい読んでから（略
設計が（略→お前の能力が（略
要件が（略→お前の理解が（略
と自分のコードとか脳内理解とかを疑う前に他所の粗探し
ばかりするので、まっとうな低レイヤ住民のエンジニアとしては
嫌気が差すことばかりだろうし無視したくなる気もわかる。
Re:教訓 (スコア:5, 興味深い)
ユーザやアプリ屋さんから、
「お前のドライバがおかしい。うちはちゃんとやっているのに！」
とクレームを受けることもよくあります。
逆に、ドライバ開発をやっていると
「OSがおかしい」、「ハードウェアがおかしい」
としかどうしても思えない場面は意外とよくあります。
前者の場合、よく調べてみるとやはりアプリ側が悪いことが多いのですが、
かなり証拠を用意しても(ログとか)なかなか信じてもらえず嫌になることが多いです。
なので後者のときも、自分が悪い可能性を慎重に調査をして、それでもどうしても
OSがおかしいということになってから、OSベンダにサポート依頼を行うのですが、
やはりそれでも結局自分が悪かった、という結果が返ってくることも多いです。
(名誉のために言っておくと、OSのバグが見つかることも結構あります)
OSとかドライバとか低層作る仕事やるには、
「お前が悪い」といわれたときは真摯に対応して、
結果もし自分が潔白だったとしたら
「ああ良かった、バグはなかったんだ！」
と思えるくらいの境地が必要だと思えるようになってきた今日この頃です。
なかなか境地にたどり着けませんが。