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

提供: ArchWiki
ナビゲーションに移動 検索に移動
(→‎Bisecting: 翻訳)
66行目: 66行目:
 
}}
 
}}
   
== Speeding up builds ==
+
== ビルドの高速化 ==
   
  +
=== より小さなカーネルを構築する ===
=== Building smaller kernel ===
 
   
  +
[[modprobed-db]] を使ってローカルシステムに必要なモジュールだけをビルドしたり、 {{ic|make localmodconfig}} によってカーネルビルド時間を短縮することができます。もちろん、例えばネットワークの問題をデバッグするためのサウンドドライバなど、無関係なドライバを完全に削除することも可能です。
You can shorten kernel build times by building only the modules required by the local system using [[modprobed-db]], or by {{ic|make localmodconfig}}. Of course you can completely drop irrelevant drivers, for example sound drivers to debug a network problem.
 
   
=== Ccache ===
+
=== キャッシュ ===
   
  +
{{ic|gcc}} を使ってビルドされた大きなプロジェクトを二分する場合、 [[ccache]] を有効にすることでビルド時間を短縮できるかもしれません。しかし、キャッシュの効果を実感できるまでには、何度かビルドを繰り返す必要があるかもしれません。キャッシュがヒットする可能性は、一般に切断点間の距離が短くなるにつれて高くなります。
If you are bisecting a large project built using {{ic|gcc}}, it might be possible to reduce build times by enabling [[ccache]]. It may take several build iterations before you start to see benefits from the cache, however. The likelihood of cache hits generally increases as the distance between bisection points decreases.
 
   
  +
{{Note|キャッシュが有効なのは、''まったく同じ'' ソースをコンパイルするときだけです。また、カーネルを bisect するために {{ic|make clean}} をする必要は ''無い'' ので、 ccache は完全に無駄であることを意味します}}
{{Note|Ccache is effective ''only when'' compiling ''exactly identical'' sources. And to bisect the kernel, it is ''not'' necessary to do {{ic|make clean}}, meaning ccache is a complete waste.}}
 
   
 
== Restoring package ==
 
== Restoring package ==

2022年2月8日 (火) 01:32時点における版

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 を実行する必要があるかもしれません。
  • 実際にゼロまでのステップ数をカウントダウンするので、最初の悪いコミットを指定するまで止めないことが重要です。

ビルドの高速化

より小さなカーネルを構築する

modprobed-db を使ってローカルシステムに必要なモジュールだけをビルドしたり、 make localmodconfig によってカーネルビルド時間を短縮することができます。もちろん、例えばネットワークの問題をデバッグするためのサウンドドライバなど、無関係なドライバを完全に削除することも可能です。

キャッシュ

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

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

Restoring package

Reverting to an original version of the package can be done by installing the package from repositories with pacman.

See also