第9章 バグの報告と対処

報告者は問題のあるカーネルバージョンの環境下で reportbug か、それ以外の bug スクリプトを実行するツールを使用することを期待されます。この情報のない報告に対する回答は、reportbug を使用したフォローアップの要求でなくてはなりません。要求があってから 1 ヶ月以内にこれらの情報を私達が受け取らなかった場合、バグは閉じられる場合がります。

例外:

多くの報告者がバグの深刻度合いを間違えてバグ報告をします。私たちは次のように基準を解釈し、必要に応じて深刻度を調整しています。

私達はユーザタグを使用しません。バグのトリアージを支援するために、私達は BTS で定義された標準のタグと、forwarded フィールドを使用するべきです。とりわけ：

一般的には、よく似たハードウェアを所有していない限りバグの再現はあまり期待できません。次のことを考慮すべきです：

報告者の技術的な洗練度と、疑いのあるシステムに要求されるサービスの度合い (例えばそれが製品のサーバである等) によって、私たちは次のいずれかのリクエストをすることができます。

特定の製品やコンポーネントで、アップストリームにとっての現行または以前の stable リリースでバグが発生し、わたしたちには修正できない場合は、報告者にbugzilla.kernel.orgでアップストリームにバグを報告し、わたしたちにアップストリームのバグ番号を報告するようお願いします。わたしたちがバグを直接報告することはありません。アップストリームからのフォローアップの質問はわたしたちではなく、報告者に行くべきだからです。アップストリームのバグ番号の報告をもって、わたしたちはバグを forwarded としてマークします。bts-link とそのステータスの更新

多くのバグ報告者が特徴的なエラーメッセージを探し出し、これを特定のバグであるかのように扱います。これは多くの 'me too' follow-ups の原因になっています。例えば、ドライバのバグを示すメッセージがある場合、2番目の報告者が別のドライバを使用しているようなケースです。

報告が複数の異なるバグに関する情報で溢れないように、

オリジナルのバグ報告に 1 つよりも多くのバグについて説明されている場合は('...and other thing...' )、クローンしてそれぞれ個別に対応すべきです。

パッチは通常であれば、適用される前に (古いバージョンのカーネルに対して必要な調整については別にして) 関係している上流のメンテナによってレビューされ、受け入れられます。

報告者に対しては常に丁寧に対応すべきです。これは、社会契約で示唆されているだけではなく、バグを迅速に解決することにも繋がる場合があります。報告者が深刻度を過剰にしてしまった場合は、静かにダウングレードしましょう。報告者が何か愚かなことをしてしまった場合は、それを取り消して報告し直すよう要求しましょう。'Sorry' と 'please' を付けるだけで、印象が大きく変わります。

報告者への一般的なアドバイスは https://wiki.debian.org/DebianKernelReportingBugs でメンテされています。

ローカル環境でバグが簡単に再現できても、開発者が再現できない場合 (このような場合の多くはワークフローかハードウェアに依存したバグです)、いくつかのバージョンでコンパイルとテストを行い、どの変更がリグレションの原因になったのかを絞り込むと役に立ちます。

まずは vanilla カーネルで問題を再現させましょう:

# apt-get install git build-essential
$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
$ cd linux

上記のコマンドで vanilla カーネルを取得します。「Debian カーネルソースからカスタムカーネルをビルドする」で説明されている、バイナリパッケージの設定、ビルド、テストを行います:

$ make localmodconfig  #最低限の設定
$ scripts/config --disable DEBUG_INFO  #ビルドサイズを適度なサイズにおさえる
$ make deb-pkg
# dpkg -i ../linux-image-3.5.0_3.5.0-1_i386.deb  #パッケージ名は適当なもに置き換える
# reboot

もしバグが再現できない場合は、/boot 内の公式な設定ファイルで試してみましょう。(それでも再現できない場合は勝利宣言をし祝杯を挙げましょう。)

bisection (二分探索) を開始するにはまず、どのバージョンが動作してどのバージョンが動作しなかったかを宣言します:

$ cd linux
$ git bisect start
$ git bisect good v3.0  #問題ないことがわかっているバージョン (good)
$ git bisect bad  #現在のバージョンは問題がある (bad)

git が中間バージョンをテストするためにチェックアウトします。準備しておいた設定を再利用し、ビルドしましょう。

$ make silentoldconfig
$ make deb-pkg

パッケージをインストールし、再起動させ、テストします。

$ git bisect good  #このバージョンではバグが無い 
$ git bisect bad   #バグが存在する 
$ git bisect skip  #他のバグがあるためテストが難しい

そして次のイテレーションに移ります:

$ make silentoldconfig
$ make deb-pkg

プロセスの最後に、"first bad commit" の名前が出力されます。これはバグを追うのに役立ちます。特定には至らなくても、何度かプロセスを繰り返しリグレッションの範囲を絞り込むことは有用です。その場合、git bisect log コマンドを実行し、ログを出力します。 もし可視化したければ、git bisect visualize を gitk パッケージをインストールした状態で使用することで、ステップ間で何が起きたかを見ることができます。

Christian Couder の文章、「git bisect でリグレッションと戦う」 に詳細な説明があります。kernel.org から入手することができます。または、git-doc package を参照してください。