バグを発見する典型的なやり方ってありますか？ 237
ストーリー by yoosee
まず再現方法を教えてください… 部門より
まず再現方法を教えてください… 部門より
あるAnonymous Coward曰く、"Mu: 経由で、「w3mのデバッグの記録」というのを読んだ。
w3mのバグを修正した時の記録です。バグ修正のケーススタディ的な物があると有用かなと思ったので、公開します。時々、じっとログを眺めていたかと思うと「キター」とかいってバグを発見するヒトもいるのですが、みなさんはバグを発見するための定石などありますか？聞いてみたいです。"
バグの発見方法
* なにはともあれ、ktrace
* fstatでオープンしているファイルの状態を見る
* w3mのソースからgzipの処理部を探す
* pcloseが呼ばれているのかを検証
* pcloseではクローズできないpipeがある?
* pipeをオープンする方法は、popenだけではない
who (スコア:5, すばらしい洞察)
振り出しに戻る (スコア:2, おもしろおかしい)
誰が書いたかで予断を抱え込むような人の書いたモノは怪しい…
当たり前のことですが (スコア:5, 参考になる)
何が起こっているのか正確に把握するってのが一番大事。coreだのktraceだfstatだってのもそのための道具な訳で。「よくわからないんでそれらしいところをいじったら直りました」ってのは最悪。「そりゃ症状が消えただけだろ!! 直ったかどうかなんてわからないだろ!!」とよく怒鳴ったものです。
Re:当たり前のことですが (スコア:4, すばらしい洞察)
正常な状態、あるべき姿はどんなものかを正確に把握していること。
これにつきる。
あたりまえだけど。
一番の方法は (スコア:5, すばらしい洞察)
#それができれば苦労はしないですけど…
Re:一番の方法は (スコア:2, おもしろおかしい)
Re:一番の方法は (スコア:2, おもしろおかしい)
そして頭にキーボードどの痕が・・・
Re:一番の方法は (スコア:2, 参考になる)
# 直せるかどうかは別
告白デバッグ (スコア:5, 興味深い)
Re:告白デバッグ (スコア:5, 興味深い)
何か不具合や質問があったとき、事務員に聞く前にまずこのクマさんに一度話してからでないといけないとか。
で、質問者の半数はクマさんが解決してくれるそうです。
#ネタ元なんだったっけ、なにか有名な話のような気も
Re:告白デバッグ (スコア:4, 参考になる)
Re:告白違い (スコア:4, おもしろおかしい)
・・・あんたのためにやってるんじゃないんだからね！！」
これでモチベーションもアップ。
#する人としない人、どっちが多いだろう。
---にょろ～ん
Re:告白違い (スコア:4, おもしろおかしい)
自分で言っても萌えませんorz
修正版。
自分「これこれこういうことをしようとしているんだけど・・・」
相手「なんで私が見なくちゃ行けないのよ。
・・・あんたのためにやってるんじゃないんだからね！！」
---にょろ～ん
Re:告白デバッグ (スコア:3, おもしろおかしい)
Re:告白デバッグ (スコア:4, おもしろおかしい)
「聞いてアロエリーナ、ちょっと言いにくいんだけど～」
と(確かサーバラックに)言ってたら、近くの人に本気で心配されました。
# ちょっとしたお茶目のつもりだったんだけど。
Re:告白デバッグ (スコア:3, 参考になる)
自分のbugも去る事ながら、仕様の矛盾点まで露呈してしまい、bugだか仕様だか、もめた事数知れず。
#bugをトレースするプログラムを書いて、そいつにbugがあって...以下循環参照orz
Re:告白デバッグ (スコア:3, すばらしい洞察)
わかる。自分で言葉にして説明してみることって、重要よね。それだけでかなりの情報を自分の頭の中で整理することができる。
プログラミングに限った話じゃないけど。
むらちより/あい/をこめて。
Re:告白デバッグ (スコア:2, 興味深い)
暗い顔で説明している新人の表情がパァっと明るくなっていくのがとても快感でした。
講師すら外れて久しいのでAC
Re:告白デバッグ (スコア:3, おもしろおかしい)
リリースする (スコア:5, おもしろおかしい)
#発見できても逃げられる=二度と再現できない場合が多々あるのが璧に傷
とりあえずタイムカードを入れる (スコア:5, おもしろおかしい)
Re:とりあえずタイムカードを入れる (スコア:4, おもしろおかしい)
デバッグパターン (スコア:5, 参考になる)
まだ紹介されていないようなので。
「デバッグパターン」 [fc2web.com]
このストーリーで紹介された手法のかなりの部分が、ここですでに網羅されています。
中でも身につまされたのが、これ。
（末尾の強調は引用者による）
Re:デバッグパターン (スコア:3, おもしろおかしい)
c = c / 2; /* 答えが倍になるため */
ってソースをスタッフが書いてました orz
で、そいつは
a = b + 1;
a = b + 1; /* 念のため。たまに答えがおかしいので */
ってコードも書いてました orz
みんつ
機械に見つけさせる (スコア:5, 参考になる)
FindBugs [sourceforge.net]
PMD [sourceforge.net]
Lint4j [jutils.com]
codewizard [techmatrix.co.jp]
DevPartner Studio Professional Edition [compuware.co.jp]
COReTOOL/PGRelief [fujitsu.com]
QAC [toyo.co.jp]
QAC++ [toyo.co.jp]
などなど…
C/C++向けで自由にルールが作成できるオープンソースの実装は無いものか．
Re:機械に見つけさせる (スコア:3, 参考になる)
Splint [splint.org]
RATS [securesoftware.com]
Uno [spinroot.com]
などが有りますね。
UnoはCにしか対応していませんが、自分でルールを書けるようです。
O'ReillyのSecure Coding: Principles & Practices [securecoding.org]に、
静的解析以外の(動的解析など)ツールも含めて色々載ってます。
valgrind (スコア:4, 参考になる)
まだ誰も書いてない。しめた！今のうち… (スコア:4, おもしろおかしい)
2. バグを取り除き、接点を掃除します。
3. パネルを閉じ、コンピューターの動作を確認します。
Re:まだ誰も書いてない。しめた！今のうち… (スコア:2, おもしろおかしい)
ここに書いてあることを、手当たりしだいにやってる人がいるんだから！
Re:まだ誰も書いてない。しめた！今のうち… (スコア:2, 興味深い)
参考資料 [hp.com]
ホッパー女史を呼んでくれ (スコア:2, おもしろおかしい)
＃「点検時にVirusを発見。」と、日誌にテープで貼り…。蔓延(笑)
バグを発見するのか、バグの原因を発見するのか (スコア:3, すばらしい洞察)
寝バッグ (スコア:3, 参考になる)
目覚めてから確認すると、そのものずばりだったり。
(全然見当はずれな内容だったり、既に修正済のバグについて必死で原因を探す夢だったりすることも…)
まあ、昼間ずっと考えていた内容が、寝ている間に整理されてるのだと思っていますが、
デバッガでコードを一行ずつトレース実行しつつ、監視式を表示して確認し、
「ここだっ、ここでバグってる!」って感じでバグを見つけるという夢を見たことも。
それで正解だったのですが、私の脳はCPUのエミュレーション機能を持っているのかどうか不思議です…
assert(3) (スコア:3, 興味深い)
assert はソースに残しておいても -DNDEBUG でリリース版ではコード生成させないで済むし、書き手が何を「ありえない状態」と仮定しているがソースに残ってドキュメント性もちょっと上がります。
あと、どうやってコード上の異常な場所まで来たかはカバレジテスタやプロファイラを使って調べる事もあります。
オカルトにだって頼っちゃうよ！ (スコア:3, おもしろおかしい)
* ソースリストプリントアウト
* 髪の毛にクリップを結びつける
* １ページずつ髪の毛の先にぶら下げたクリップをかざす
* 反応したページを抽出
* 一行ずつクリップをかざす
* 反応した行に注目
ええ、もちろん最終手段ですよ。もう、なにがなんだかワカラン！いっそ殺してくれ！オレを殺してくれ！ってなマトモじゃない精神状態ですよ。一回だけですよ！もうしませんよ！許してください…。
でも解決したよ(笑)
初心者にテストしてもらう (スコア:3, 興味深い)
これでけっこうバグが見つかります。
ただし、どう操作してバグが出たのかを説明するスキルはないので、
同席して操作をきっちり見張る必要があります。
w3m の cvs レポジトリを修正 (スコア:3, 参考になる)
# 他にも未反映の patch が溜まってるんですが…
もちろん (スコア:2, 興味深い)
デバグ完了後も消さないので、コメントアウトされたprintfの類がたくさん残ります。
はいはい、言わなくてもわかってるよ。けど、そのprintfの山を見てるのも好きなんだよね。戦績ってかんじか？
Re:もちろん (スコア:5, 興味深い)
デバッグオプション付きでコンパイル →正常に動く
最適化オプション付きでコンパイル →異常動作
最適化オプション付きでprintf埋め込んでコンパイル →正常に動く
ってのがありました。
原因はある変数の初期化漏れで、printf埋め込みで運良く初期化されてしまうのがこのような現象を引き起こしてました…
＃最近のコンパイラなら「初期化されてないぞー」って騒がれるとこだとおもいますが、アノ頃はそんなものはなかった…
いぁほんとに悩みましたこれ…ダミーのprintf残したままテスト終了にしようと何度思ったことか…
Re:もちろん (スコア:3, 参考になる)
決められた処理時間(ms)内にAckを返さないと行けない
処理の中でprintf使って、
「なんで正常に動かないんだろぉ~」とハマった事が
あります。printfって遅いのね･･････。
デバグの為にバグ生んで何やってんだかと。
Re:もちろん (スコア:4, すばらしい洞察)
#後日、オンにすることはまず無かったりして ;-)
タブレット中毒者。
人柱。 (スコア:2, おもしろおかしい)
大規模なシステムでは使えないケド。
Re:人柱。 (スコア:2, すばらしい洞察)
それはそうと、エンドユーザーにではないけど社内の別の部隊にいじらせて
バグ出し、仕様ミス(不整合)、マニュアル類との整合性なんかの評価は
やってるところも多いのでは？
F、I、N (スコア:3, おもしろおかしい)
タブレット中毒者。
誰が作ったプログラムか、で異なる (スコア:2, 興味深い)
■他人が作ったものの場合
むしろコンパイルできなくって困ること
(つまり configure.in, Makefile.in のバグ)のほうが
多いんだけど。
非x86Linuxの環境を使っている方はどーですか。そんなことないですか。
CFLAGS や LDFLAGS を無視する Makefile.in を見ると
腹が立ってきたりしませんかそうですか。
# mishimaは本田透先生を熱烈に応援しています
ロジアナを繋ぐ！ (スコア:2, 参考になる)
未使用I/Oピンに出力させておいて、ロジアナで信号波形観測です！
まずこいつが“L”で、こっちが“H”で、その2クロック後にこの信号が…
ん…ここが動いてないところか…
（で、ソースの該当部分をよく見る…）
あ、ごめん、ステートマシンの飛び先ステート値、間違ってました(^^;)
え？ ハードウェアな人はお呼びでない？ 失礼しました…
（HDLはほとんどソフト感覚なんですが^^;）
Re:やっぱり便所が一番。 (スコア:3, 参考になる)
枕上……寝る前に寝床でぼ～っとしている時
厠上……便所の中でぼ～っとしている時
馬上……移動中ぼ～っとしている時
Re:やっぱり便所が一番。 (スコア:2)
「馬上（馬上）」「枕上（ちんじょう）」、「厠上（しじょう）」
It's not who is right, it's who is left.
だくだく (スコア:2, おもしろおかしい)
>1インストラクション／秒でブート完了するまで1週間ぐらいかからない？
そこはそれ、「ブートしたつもり」「初期化したつもり」「処理したつもり」…
で、バグが出そうなところまでは突き進むワケですよ。
#「バグ修正が完了したつもり」「修正版が提供されたつもり」
#※参考資料 [so-net.ne.jp]
タブレット中毒者。
Re:あらかじめ (スコア:4, 興味深い)
テスト項目が不足してるとかでもないのに現実に発生していたバグはその1/100足らず。それもそのはず設計段階から徹底的にバグを出さないシステム構築を心がけていましたし、その成果からか出ていたバグもごく一部を除けばコーディング中の単純ミスなどのありがちな原因によるものばかり。しかし客先は必ずこれだけの数のバグ票を出せ、出さないと納品を受け付けないとの一点張り。やむを得ずドキュメントの誤字や、本来はバグではない見栄えの調整などまでバグとして盛り込んで無理矢理件数を増やしました…。
＃というか、それまで業務依頼していたソフト会社がバグ出し過ぎなのではないかと…。