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

提供: ArchWiki
ナビゲーションに移動 検索に移動
(→‎Bisecting: 翻訳)
 
(2人の利用者による、間の4版が非表示)
66行目: 66行目:
 
}}
  
}}
   
−
== Speeding up builds ==
 +
== ビルドの高速化 ==
   
−
=== Building smaller kernel ===
 +
=== キャッシュ ===
   
  +
{{ic|gcc}} を使ってビルドされた大きなプロジェクトを二分する場合、 [[ccache]] を有効にすることでビルド時間を短縮できるかもしれません。しかし、キャッシュの効果を実感できるまでには、何度かビルドを繰り返す必要があるかもしれません。キャッシュがヒットする可能性は、一般に切断点間の距離が短くなるにつれて高くなります。
−
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.
  
   
  +
{{Note|キャッシュが有効なのは、''まったく同じ'' ソースをコンパイルするときだけです。また、カーネルを bisect するために {{ic|make clean}} をする必要は ''無い'' ので、 ccache は完全に無駄であることを意味します}}
−
=== 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.
  
   
  +
元のバージョンのパッケージに戻すには、[[pacman]] を使ってリポジトリからパッケージをインストールします。
−
{{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 ==
 +
== 参照 ==
   
  +
* [https://git-scm.com/docs/git-bisect-lk2009.html git bisect によるリグレッションとの戦い]
−
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]
  
 
* {{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 を使ってリポジトリからパッケージをインストールします。

参照

「https://wiki.archlinux.jp/index.php?title=Git_でバグを_bisect_する&oldid=34826」から取得