Git でバグを bisect する

Mesa や Linux カーネルなどのプロジェクトで発生したバグを報告する際、 問題のあるコミットが何であるかを確認するために、最後に動作した既知のバージョン と問題のある新しいバージョンとの間でバイセクトを行うよう求められることがよくあ ります。Arch では、AUR の機能のおかげで、これは非常に簡単に行うことができます。

古いリリースに戻す場合

問題を引き起こしているのが新しいパッケージのリリースであることを確認することは有用かもしれません。Arch での パッケージのダウングレード は、古いバージョンのパッケージがシステムにキャッシュとして保存されていれば、簡単に実行できます。

ノート: 古いバージョンで問題が解決されたとしても、それはプログラムのバグではなく、Arch が提供するパッケージの問題である可能性があります

git からのパッケージの構築

bisect を行うには、git からパッケージのバージョンをビルドする必要があります。これは AUR から -git パッケージをビルドすることで実現できます。

bisect のセットアップ

パッケージのビルドが成功したら、src/ ディレクトリ内の git ルートディレクトリに移動する必要があります。git ルートディレクトリの名前は、多くの場合pkgname と同じです。(または接尾辞 -git を除いたもの）

$ cd src/git_root

そこから、bisecting するプロセスを開始できます:

$ git bisect start

次のコマンドは、bisecting する場所を指定するために使用できるすべてのタグを表示します:

$ git tag

前の例に続いて、バージョン oldver は機能したが、newver は機能しなかったと想定します。

$ git bisect good oldver
$ git bisect bad newver

良いバージョンと悪いバージョンのタグが付けられたので、コミットのテストに進むことができます。

Bisecting

PKGBUILD のあるディレクトリに戻ります。前のセクションで説明したディレクトリにまだいる場合は、次のように実行できます:

$ cd ../..

これで、パッケージの特定のリビジョンを再構築してインストールできます:

$ makepkg -efsi

ノート: そうでなければ、あなたが行ったすべての変更を削除してしまうので、-e という接頭辞をそのままにしておくことが非常に重要です

新しいパッケージがインストールされたら、以前発見したエラーをテストすることができます。前のセクションで行ったディレクトリに戻ります。

$ cd src/git_root

問題が発生した場合は、リビジョンが不良であったことを伝えてください:

$ git bisect bad

問題が発生しなかった場合は、リビジョンが良かったことを伝えてください:

$ git bisect good

そして、このセクションの冒頭で説明したことをもう一度行い、git bisect が問題のあるコミットを指定するまで繰り返します。

ノート:

• git bisect コマンドを発行した後に、make clean を実行する必要があるかもしれません。
• 実際にゼロまでのステップ数をカウントダウンするので、最初の悪いコミットを指定するまで止めないことが重要です。

ビルドの高速化

キャッシュ

gcc を使ってビルドされた大きなプロジェクトを二分する場合、 ccache を有効にすることでビルド時間を短縮できるかもしれません。しかし、キャッシュの効果を実感できるまでには、何度かビルドを繰り返す必要があるかもしれません。キャッシュがヒットする可能性は、一般に切断点間の距離が短くなるにつれて高くなります。

ノート: キャッシュが有効なのは、まったく同じ ソースをコンパイルするときだけです。また、カーネルを bisect するために make clean をする必要は 無い ので、 ccache は完全に無駄であることを意味します

パッケージの復元

元のバージョンのパッケージに戻すには、pacman を使ってリポジトリからパッケージをインストールします。

参照

• git bisect によるリグレッションとの戦い
• git-bisect(1)
• Gentoo:Kernel git-bisect