Linux Kernel 2.2 Documentation:
/usr/src/linux/Documentation/BUG-HUNTING
BUG-HUNTING
KernelのBugを見つける方法
[プレインテキスト版]
- 原著作者: Larry McVoy <lm@sgi.com>
- 翻訳者: 早川 仁 <uv9h-hykw@asahi-net.or.jp>
- バージョン: 2.2.0
- 翻訳日時: 1999/04/19
[Sat Mar 2 10:32:33 PST 1996 KERNEL_BUG-HOWTO lm@sgi.com (Larry McVoy)]
This is how to track down a bug if you know nothing about kernel hacking.
It's a brute force approach but it works pretty well.
この文書では、あなたがカーネルのハッキングについて知らない場合に
どのようにしてバグを見つけだすか、という事について説明しています。
力業ではありますが，ちゃんと使える方法です．
You need:
必要なのは：
. A reproducible bug - it has to happen predictably (sorry)
. All the kernel tar files from a revision that worked to the
revision that doesn't
・再現するバグ − 再現させる方法がわかっている必要があります。
・正常動作するものから動作しないものまでの全リビジョンの
カーネル tar ファイル
You will then do:
それから次の作業を行ってください：
. Rebuild a revision that you believe works, install, and verify that.
. Do a binary search over the kernels to figure out which one
introduced the bug. I.e., suppose 1.3.28 didn't have the bug, but
you know that 1.3.69 does. Pick a kernel in the middle and build
that, like 1.3.50. Build & test; if it works, pick the mid point
between .50 and .69, else the mid point between .28 and .50.
. You'll narrow it down to the kernel that introduced the bug. You
can probably do better than this but it gets tricky.
・正常に動作するだろうと思われるリビジョンをリビルド、
インストールして動作を検証してください。
・カーネル内をバイナリーサーチ（訳注：バイナリーファイルをサーチ
することではなく、目的の数値、最大／最小値の比較を行い、中間値を
取得して、その値と、最大値／最小値を比較・・・と繰り返してサー
チを行うことです。２分探索とも言われます）してどのリビジョン
からバグが含まれているかを見つけてください。例えば、1.3.28 には
バグが無いが、1.3.69 にはバグがあることがわかったとします。
次に中間（例えば 1.3.50）のカーネルをビルド、テストします。
正常動作した場合、.50〜.69の中間の、動作しなかった場合
.28〜.50 の中間のリビジョンで同じように繰り返します。こうする
ことによって、バグが混入されたリビジョンを見つけることができま
す。上記より良い方法で該当リビジョンを見つける事もできますが、
その場合は少々トリッキーな方法になるでしょう。
. Narrow it down to a subdirectory
・変更点をサブディレクトリ単位に絞り込む
- Copy kernel that works into "test". Let's say that 3.62 works,
but 3.63 doesn't. So you diff -r those two kernels and come
up with a list of directories that changed. For each of those
directories:
- 正常に動作するカーネルを "test" ディレクトリにコピーします。
例えば 3.62 が正常動作するもので、3.63 が動作しないものだとしま
す。2 つのカーネルを diff -r して、変更されたディレクトリの
リストを得ます。そのリスト内の各ディレクトリに対して、
Copy the non-working directory next to the working directory
as "dir.63".
One directory at time, try moving the working directory to
"dir.62" and mv dir.63 dir"time, try
正常動作しないディレクトリを正常動作するディレクトリと
同じ階層に "dir.63" などという名前にしてコピーします。
正常に動作するディレクトリと、動作しないディレクトリの
名前を次のように変えてみてください。
mv dir dir.62
mv dir.63 dir
find dir -name '*.[oa]' -print | xargs rm -f
And then rebuild and retest. Assuming that all related
changes were contained in the sub directory, this should
isolate the change to a directory.
それから再テストするためにリビルドしてください。依存関係
にある変更部分は全てそのサブディレクトリ内に含まれている
と仮定すると、変更された点をディレクトリの中だけにするこ
とができるはずです。
Problems: changes in header files may have occurred; I've
found in my case that they were self explanatory - you may
or may not want to give up when that happens.
問題点：ヘッダーファイル内が変更がされた可能性もあります。
私のみつけたケースの場合は説明の必要もないくらいはっきり
したものでしたが - 諦めたくなるケースもあるかもしれません。
. Narrow it down to a file
・変更点をファイル単位に絞り込む
- You can apply the same technique to each file in the directory,
hoping that the changes in that file are self contained.
- ディレクトリ内の各ファイルに対して、変更点はそのファイル内に
含まれていると仮定します
. Narrow it down to a routine
・変更点を処理単位で探す
- You can take the old file and the new file and manually create
a merged file that has
- 新旧のリビジョンのファイルからルーチンを次のようにして手動で
マージします。
#ifdef VER62
routine()
{
...
}
#else
routine()
{
...
}
#endif
And then walk through that file, one routine at a time and
prefix it with
それからマージ後のファイルを、1 つのルーチンごとに次のように
prefix を指定して動作を見ていってください。
#define VER62
/* both routines here */
#undef VER62
Then recompile, retest, move the ifdefs until you find the one
that makes the difference.
そして再コンパイル、再テストを行い、新旧両者で動作が違う（
つまりバグの発生している）部分を見つけるまで ifdef の部分を
移していってみてください（訳注：つまり、バグの発生するルーチ
ンを見つけるまで、一度に１ルーチンにだけ #ifdef をつけてテス
トしていきなさい、ということを言っています）。
Finally, you take all the info that you have, kernel revisions, bug
description, the extent to which you have narrowed it down, and pass
that off to whomever you believe is the maintainer of that section.
A post to linux.dev.kernel isn't such a bad idea if you've done some
work to narrow it down.
最後に集めた情報 − カーネルのリビジョン、バグの説明、変更点の探索を行い
見つけだした機能拡張の部分 − をその（バグの出た）セクションのメンテナー
だと思われる人に渡してください。linux.dev.kernel にポストしてもよいでしょう。
既に問題点の範囲を絞ってさえいればですが。
If you get it down to a routine, you'll probably get a fix in 24 hours.
もしも問題点の範囲をルーチンにまで絞っているのであれば、おそらく 24 時間
以内に問題点は修復されるでしょう。
My apologies to Linus and the other kernel hackers for describing this
brute force approach, it's hardly what a kernel hack would do. However,
it does work and it lets non-hackers help bug fix. And it is cool
because Linux snapshots will let you do this - something that you can't
do with vender supplied releases.
Linux や他のカーネルハッカー達には、この荒っぽい強引な方法での説明につい
て謝らなければいけません。カーネルハックの時にやるべきこととは言えないか
もしれません。ですが、これでも問題点を発見することは可能ですし、ハッカー
以外の人たちにもバグフィックスの手助けをしてもらえます。このようなことが
できるのは素晴らしいことです。これは Linux のスナップショットが公開され
ているおかげですね。ベンダー製の物ではできないことです。（訳注：つまりベ
ンダー製の Unix とは違いソースが公開されているからこそ、このような方法で
バグの追跡ができ、そして迅速なバグフィックスがされるというオープンソース
の利点のことです）
---------------
日本語訳：早川 仁 (1999/04/18)
Linux カーネル 2.2 付属文書一覧へ戻る