「Git でバグを bisect する」の版間の差分

提供: ArchWiki
ナビゲーションに移動 検索に移動
 
(2人の利用者による、間の3版が非表示)
67行目: 67行目:
   
 
== ビルドの高速化 ==
 
== ビルドの高速化 ==
 
=== より小さなカーネルを構築する ===
 
 
[[modprobed-db]] を使ってローカルシステムに必要なモジュールだけをビルドしたり、 {{ic|make localmodconfig}} によってカーネルビルド時間を短縮することができます。もちろん、例えばネットワークの問題をデバッグするためのサウンドドライバなど、無関係なドライバを完全に削除することも可能です。
 
   
 
=== キャッシュ ===
 
=== キャッシュ ===
78行目: 74行目:
 
{{Note|キャッシュが有効なのは、''まったく同じ'' ソースをコンパイルするときだけです。また、カーネルを bisect するために {{ic|make clean}} をする必要は ''無い'' ので、 ccache は完全に無駄であることを意味します}}
 
{{Note|キャッシュが有効なのは、''まったく同じ'' ソースをコンパイルするときだけです。また、カーネルを bisect するために {{ic|make clean}} をする必要は ''無い'' ので、 ccache は完全に無駄であることを意味します}}
   
  +
== パッケージの復元 ==
== Restoring package ==
 
   
  +
元のバージョンのパッケージに戻すには、[[pacman]] を使ってリポジトリからパッケージをインストールします。
Reverting to an original version of the package can be done by installing the package from repositories with [[pacman]].
 
   
== See also ==
+
== 参照 ==
   
* [https://git-scm.com/docs/git-bisect-lk2009.html Fighting regressions with git bisect]
+
* [https://git-scm.com/docs/git-bisect-lk2009.html git bisect によるリグレッションとの戦い]
 
* {{man|1|git-bisect}}
 
* {{man|1|git-bisect}}
 
* [[Gentoo:Kernel git-bisect]]
 
* [[Gentoo:Kernel git-bisect]]

2023年11月14日 (火) 22:36時点における最新版

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 を使ってリポジトリからパッケージをインストールします。

参照