Merge the following changes in the English version:
hackers.sgml : 1.4 -> 1.6 Submitted by: HARADA Kiroh <kiroh@pp.iij4u.or.jp>
This commit is contained in:
Motoyuki Konno
parent
50d39f7b02
commit
3639938984
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=3608
2 changed files with 400 additions and 6 deletions
|
|
@ -1,6 +1,6 @@
|
||||||
<!-- $Id: hackers.sgml,v 1.4 1998-09-06 13:15:50 motoyuki Exp $ -->
|
<!-- $Id: hackers.sgml,v 1.5 1998-10-15 16:19:10 motoyuki Exp $ -->
|
||||||
<!-- The FreeBSD Japanese Documentation Project -->
|
<!-- The FreeBSD Japanese Documentation Project -->
|
||||||
<!-- Original revision: 1.4 -->
|
<!-- Original revision: 1.6 -->
|
||||||
|
|
||||||
<sect>
|
<sect>
|
||||||
<heading>まじめな FreeBSD ハッカーだけの話題<label id="hackers"></heading>
|
<heading>まじめな FreeBSD ハッカーだけの話題<label id="hackers"></heading>
|
||||||
|
|
@ -265,5 +265,202 @@
|
||||||
これらの番号を使用してください. どちらの場合であれ, ドライバに関する情報を
|
これらの番号を使用してください. どちらの場合であれ, ドライバに関する情報を
|
||||||
<tt><freebsd-hackers@FreeBSD.ORG></tt> に流して頂けると助かります.
|
<tt><freebsd-hackers@FreeBSD.ORG></tt> に流して頂けると助かります.
|
||||||
|
|
||||||
</sect>
|
<sect1>
|
||||||
|
<heading>代替のディレクトリ配置ポリシー</heading>
|
||||||
|
<p>
|
||||||
|
|
||||||
|
現在使われているディレクトリの配置ポリシーは, 私が 1983 年に書い
|
||||||
|
たものから全く変更されていません. 私は当初の配置ポリシーを, オリ
|
||||||
|
ジナルの fast filesystem のために書き, まったく改定していません.
|
||||||
|
このポリシーはシリンダグループを使い尽くすのを防ぐにはうまくいき
|
||||||
|
ましたが,お気づきの方もいる通り find の動作には不適切です. ほと
|
||||||
|
んどのファイルシステムの内容は, 深さ優先検索 (ftw とも呼ばれます)
|
||||||
|
によって作られたアーカイブからレストアして作成されます. この際,
|
||||||
|
ディレクトリは,シリンダグループにまたがって配置され, 以降の深さ
|
||||||
|
優先検索を行うには考え得る限り最悪の状態になります. もし作成する
|
||||||
|
ディレクトリの総数がわかっていれば, 解決方法はあります. (総数 /
|
||||||
|
シリンダグループ数)個のディレクトリをシリンダグループごとにまと
|
||||||
|
めて作成すれば良いのです. もちろん最適なディレクトリ配置になるよ
|
||||||
|
うに, 総数を予測する方法を考えなければなりません. しかし仮にシリ
|
||||||
|
ンダグループあたりのディレクトリ数を 10 くらいの小さな数に固定し
|
||||||
|
てしまったとしても, 大幅な改善が望めるでしょう. このポリシーを用
|
||||||
|
いるべきリストア作業を, 通常の作業(おそらく既存のポリシーを使用
|
||||||
|
したほうが良いでしょう)を区別するには, 10 秒間の間に作成されたディ
|
||||||
|
レクトリを最大 10 個までまとめて単一のシリンダグループに書き込む
|
||||||
|
という手順が使えるでしょう. とにかく私の結論は, そろそろ実験
|
||||||
|
を始めて見る時期だろうということです.
|
||||||
|
|
||||||
|
<sect1>
|
||||||
|
<heading>カーネルパニックを最大限に利用する</heading>
|
||||||
|
|
||||||
|
<p>
|
||||||
|
<em>[この節は, freebsd-current <ref id="mailing" name="mailing
|
||||||
|
list"> に <url url="mailto:<wpaul@FreeBSD.ORG" name="Bill Paul">
|
||||||
|
が投稿したメールを, <url url="mailto:des@FreeBSD.ORG"
|
||||||
|
name="Dag-Erling Coïdan Smørgrav"> が校正し,括弧内のコ
|
||||||
|
メントを追加して引用したものです. ]</em>
|
||||||
|
|
||||||
|
<p>
|
||||||
|
<verb>
|
||||||
|
From: Bill Paul <wpaul@skynet.ctr.columbia.edu>
|
||||||
|
Subject: Re: the fs fun never stops
|
||||||
|
To: ben@rosengart.com
|
||||||
|
Date: Sun, 20 Sep 1998 15:22:50 -0400 (EDT)
|
||||||
|
Cc: current@FreeBSD.ORG
|
||||||
|
</verb>
|
||||||
|
|
||||||
|
<p>
|
||||||
|
<em>[<ben@rosengart.com> が以下のパニックメッセージを
|
||||||
|
投稿しました.]</em>
|
||||||
|
<verb>
|
||||||
|
> Fatal trap 12: page fault while in kernel mode
|
||||||
|
> fault virtual address = 0x40
|
||||||
|
> fault code = supervisor read, page not present
|
||||||
|
> instruction pointer = 0x8:0xf014a7e5
|
||||||
|
^^^^^^^^^^
|
||||||
|
> stack pointer = 0x10:0xf4ed6f24
|
||||||
|
> frame pointer = 0x10:0xf4ed6f28
|
||||||
|
> code segment = base 0x0, limit 0xfffff, type 0x1b
|
||||||
|
> = DPL 0, pres 1, def32 1, gran 1
|
||||||
|
> processor eflags = interrupt enabled, resume, IOPL = 0
|
||||||
|
> current process = 80 (mount)
|
||||||
|
> interrupt mask =
|
||||||
|
> trap number = 12
|
||||||
|
> panic: page fault
|
||||||
|
</verb>
|
||||||
|
|
||||||
|
<p>このようなメッセージが表示された場合, 問題が起きる状況を確認し
|
||||||
|
て, 情報を送るだけでは十分ではありません. 下線をつけた命令ポインタ
|
||||||
|
値は重要な値ですが, 残念ながらこの値は構成に依存します. つまり, こ
|
||||||
|
の値は使っているカーネルのイメージに依存するのです. もしスナップショッ
|
||||||
|
トなどの GENERIC カーネルを使っているのであれば, 他の人間が問題の
|
||||||
|
ある関数について追試をすることができますが, カスタマイズされたカー
|
||||||
|
ネルの場合は, 使っている本人にしか問題の起こった場所は特定できない
|
||||||
|
のです.
|
||||||
|
|
||||||
|
<p> 何をすれば良いのでしょう？
|
||||||
|
|
||||||
|
<itemize>
|
||||||
|
<item>命令ポインタ値をメモします. <tt/0x8:/ という部分は今回必
|
||||||
|
要ありません. 必要なのは <tt/0xf0xxxxxx/ という部分です.
|
||||||
|
<item>システムがリブートしたら, 以下の操作を行います:
|
||||||
|
<verb>
|
||||||
|
% nm /kernel.that.caused.the.panic | grep f0xxxxxx
|
||||||
|
</verb>
|
||||||
|
ここで, <tt/f0xxxxxx/ は命令ポインタ値です. カーネルシンボルの
|
||||||
|
テーブルは関数のエントリポイントを含み, 命令ポインタ値は,
|
||||||
|
関数内部のある点であり, 最初の点ではないため, この操作を行っても
|
||||||
|
完全に一致するものが表示されない場合もあります. この場合は,
|
||||||
|
最後の桁を省いてもういちどやってみてください. このようになりま
|
||||||
|
す:
|
||||||
|
<verb>
|
||||||
|
% nm /kernel.that.caused.the.panic | grep f0xxxxx
|
||||||
|
</verb>
|
||||||
|
これでも一致しない場合は, 桁を減らしながら何らかの出力があるま
|
||||||
|
で繰り返してください. 何か出力されたら, それがカーネルパニック
|
||||||
|
を引き起こした可能性のある関数のリストです. これは, 問題点を見付ける
|
||||||
|
正確な方法ではありませんが, 何もないよりましです.
|
||||||
|
|
||||||
|
</itemize>
|
||||||
|
|
||||||
|
<p>このようなパニックメッセージを投稿している人はよく見掛けますが,
|
||||||
|
このように, 命令ポインタ値を, カーネルシンボルテーブルの中の関数
|
||||||
|
とつき合わせて調べている人はまれです.
|
||||||
|
|
||||||
|
<p>パニックの原因を突き止める最良の方法は, クラッシュダンプをとり,
|
||||||
|
<tt/gdb(1)/ でスタックトレースを行うことです. もちろん -current
|
||||||
|
で <tt/gdb(1)/ がちゃんと動いていればですが (私は動くことを保証
|
||||||
|
できません. ELF 化された <tt/gdb(1)/ はカーネルクラッシュダンプを
|
||||||
|
正しく扱えないと言っている人がいました. 3.0 がβテストを終える前,
|
||||||
|
に調べなければいけません. さもないと CD 出荷後に大顰蹙を買うことに
|
||||||
|
なります).
|
||||||
|
|
||||||
|
<p>
|
||||||
|
どっちにしろ, 私は普通以下のようにします.
|
||||||
|
|
||||||
|
<itemize>
|
||||||
|
<item>カーネルコンフィグファイルを作ります. カーネルデバッガが
|
||||||
|
必要そうであれば options 'DDB' を加えても良いです(私は永久ルー
|
||||||
|
プが起こっていそうな場合に, ブレークポイントを設定するのに使って
|
||||||
|
います).
|
||||||
|
|
||||||
|
<item> <tt/config -g KERNELCONFIG/ としてビルドディレクトリを設
|
||||||
|
定します.
|
||||||
|
|
||||||
|
<item><tt>cd /sys/compile/KERNELCONFIG; make</tt>
|
||||||
|
<item>カーネルのコンパイルが終了するのを待ちます.
|
||||||
|
<item><tt/cp kernel kernel.debug/
|
||||||
|
<item><tt/strip -d kernel/
|
||||||
|
<item><tt/mv /kernel /kernel.orig/
|
||||||
|
<item><tt>cp kernel /</tt>
|
||||||
|
<item>reboot
|
||||||
|
</itemize>
|
||||||
|
|
||||||
|
<p> <em>[注: 現在 3.0-BETA では, <tt/strip -d/ の代りに
|
||||||
|
<tt/strip -aout -d/ を使う必要があります.]</em>
|
||||||
|
|
||||||
|
<p> 全てのデバッグシンボルを含んだカーネルを, 実際にブートする必要は
|
||||||
|
<em>ありません.</em> <tt/-g/ をつけてコンパイルされたカーネルは,
|
||||||
|
簡単に 10MB 近くの大きさになってしまいます. こんな大きなカーネル
|
||||||
|
を実際にブートする必要はありません. この大きなカーネルイメージは
|
||||||
|
後で<tt/gdb(1)/を使うときにのみ必要です(<tt/gdb(1)/ がシンボル
|
||||||
|
テーブルを必要とするため). シンボルを含んだカーネルのコピーを保
|
||||||
|
存 しておき, <tt/strip -d/ を使ってシンボルを除いたカーネルを作
|
||||||
|
成して ブートします.
|
||||||
|
|
||||||
|
<p> 確実にクラッシュダンプをとるには, <tt>/etc/rc.conf</tt> を編
|
||||||
|
集して <tt/dumpdev/ を使用しているスワップパーティションに指定す
|
||||||
|
る必 要があります. こうすると <tt/rc(8)/ スクリプトから
|
||||||
|
<tt/dumpon(8)/ コマンドが実行されクラッシュダンプ機能が有効にな
|
||||||
|
ります. 手動で <tt/dumpon(8)/ コマンドを実行してもかまいませ
|
||||||
|
ん. パニックの後, クラッシュダンプは <tt/savecore(8)/ コマンドを
|
||||||
|
使用して取り出すこと ができます. <tt/dumpdev/ が
|
||||||
|
<tt>/etc/rc.conf</tt> で設定されていれ ば, <tt/rc(8)/ スクリプト
|
||||||
|
から <tt/savecore(8)/ が自動的に実行され, クラッシュダンプを
|
||||||
|
<tt>/var/crash</tt> に保存します.
|
||||||
|
|
||||||
|
<p> 注: FreeBSD のクラッシュダンプのサイズは, ふつう物理メモリサ
|
||||||
|
イズと同じです. つまり 64MB のメモリを積んでいれば, 64MB のクラッ
|
||||||
|
シュ ダンプが生成されることになります. <tt>/var/crash</tt> に十
|
||||||
|
分な空き 容量があることを確認してください. 手動で
|
||||||
|
<tt/savecore(8)/ を実行す れば, もっと空き容量のあるディレクトリ
|
||||||
|
にクラッシュダンプを保存でき ます. <tt/options MAXMEM=(foo)/ と
|
||||||
|
いう行をカーネルコンフィグファイ ルに追加することで, カーネルの
|
||||||
|
メモリ使用量を制限できます. たとえば 128MB のメモリがある場合も,
|
||||||
|
カーネルのメモリ使用量を 16MB に制限し クラッシュダンプのサイズ
|
||||||
|
も 128MB ではなく 16MB にすることができます.
|
||||||
|
|
||||||
|
<p> クラッシュダンプを取り出せたら, 以下のように <tt/gdb(1)/ を使っ
|
||||||
|
てスタックトレースをとります:
|
||||||
|
|
||||||
|
<p>
|
||||||
|
<verb>
|
||||||
|
% gdb -k /sys/compile/KERNELCONFIG/kernel.debug /var/crash/vmcore.0
|
||||||
|
(gdb) where
|
||||||
|
</verb>
|
||||||
|
|
||||||
|
<p> 必要な情報が 1 画面に収まらないことも多いので, できれば
|
||||||
|
<tt/script(1)/ を使って出力を記録します. strip していないカーネ
|
||||||
|
ル イメージを使うことで, 全てのデバッグシンボルが参照でき, パニッ
|
||||||
|
ク の発生したカーネルのソースコードの行が表示されているはずです.
|
||||||
|
通常, 正確なクラッシュへの過程を追跡するには, 出力を最後の行から
|
||||||
|
逆方向に読まなければなりません. また <tt/gdb(1)/ を使って, 変数
|
||||||
|
や 構造体の内容を表示させ, クラッシュした時のシステムの状態を調
|
||||||
|
べられ ます.
|
||||||
|
|
||||||
|
<p> もしあなたがデバッグ狂で, 同時に別のコンピュータを利用できる
|
||||||
|
環境にあれば, <tt/gdb(1)/ をリモートデバッグに使うこともできます.
|
||||||
|
リモートデバッグを使うと, あるコンピュータ上の <tt/gdb(1)/ を使っ
|
||||||
|
て, 別のコンピュータのカーネルをデバッグできます. ブレークポイン
|
||||||
|
トの設 定, カーネルコードのステップ実行など, ふつうのプログラム
|
||||||
|
のデバッグ と変わりません. コンピュータを 2 台並べてデバッグする
|
||||||
|
チャンスには, なかなか恵まれないので, 私はまだリモートデバッグを
|
||||||
|
試したことはあり ません.
|
||||||
|
|
||||||
|
<p> <em>[Bill による注: DDB を有効にしていてカーネルがデバッガに
|
||||||
|
落ちたら, ddb のプロンプトで 'panic' と入力すれば, 強制的にパニッ
|
||||||
|
クを 起こしクラッシュダンプさせることができます. パニックの途中
|
||||||
|
で, 再び デバッガに落ちるかもしれませんが, 'continue' と入力すれ
|
||||||
|
ば, クラッシュダンプを最後まで実行させられます.]</em>
|
||||||
|
|
||||||
|
</sect>
|
||||||
|
|
|
||||||
|
|
@ -1,6 +1,6 @@
|
||||||
<!-- $Id: hackers.sgml,v 1.4 1998-09-06 13:15:50 motoyuki Exp $ -->
|
<!-- $Id: hackers.sgml,v 1.5 1998-10-15 16:19:10 motoyuki Exp $ -->
|
||||||
<!-- The FreeBSD Japanese Documentation Project -->
|
<!-- The FreeBSD Japanese Documentation Project -->
|
||||||
<!-- Original revision: 1.4 -->
|
<!-- Original revision: 1.6 -->
|
||||||
|
|
||||||
<sect>
|
<sect>
|
||||||
<heading>まじめな FreeBSD ハッカーだけの話題<label id="hackers"></heading>
|
<heading>まじめな FreeBSD ハッカーだけの話題<label id="hackers"></heading>
|
||||||
|
|
@ -265,5 +265,202 @@
|
||||||
これらの番号を使用してください. どちらの場合であれ, ドライバに関する情報を
|
これらの番号を使用してください. どちらの場合であれ, ドライバに関する情報を
|
||||||
<tt><freebsd-hackers@FreeBSD.ORG></tt> に流して頂けると助かります.
|
<tt><freebsd-hackers@FreeBSD.ORG></tt> に流して頂けると助かります.
|
||||||
|
|
||||||
</sect>
|
<sect1>
|
||||||
|
<heading>代替のディレクトリ配置ポリシー</heading>
|
||||||
|
<p>
|
||||||
|
|
||||||
|
現在使われているディレクトリの配置ポリシーは, 私が 1983 年に書い
|
||||||
|
たものから全く変更されていません. 私は当初の配置ポリシーを, オリ
|
||||||
|
ジナルの fast filesystem のために書き, まったく改定していません.
|
||||||
|
このポリシーはシリンダグループを使い尽くすのを防ぐにはうまくいき
|
||||||
|
ましたが,お気づきの方もいる通り find の動作には不適切です. ほと
|
||||||
|
んどのファイルシステムの内容は, 深さ優先検索 (ftw とも呼ばれます)
|
||||||
|
によって作られたアーカイブからレストアして作成されます. この際,
|
||||||
|
ディレクトリは,シリンダグループにまたがって配置され, 以降の深さ
|
||||||
|
優先検索を行うには考え得る限り最悪の状態になります. もし作成する
|
||||||
|
ディレクトリの総数がわかっていれば, 解決方法はあります. (総数 /
|
||||||
|
シリンダグループ数)個のディレクトリをシリンダグループごとにまと
|
||||||
|
めて作成すれば良いのです. もちろん最適なディレクトリ配置になるよ
|
||||||
|
うに, 総数を予測する方法を考えなければなりません. しかし仮にシリ
|
||||||
|
ンダグループあたりのディレクトリ数を 10 くらいの小さな数に固定し
|
||||||
|
てしまったとしても, 大幅な改善が望めるでしょう. このポリシーを用
|
||||||
|
いるべきリストア作業を, 通常の作業(おそらく既存のポリシーを使用
|
||||||
|
したほうが良いでしょう)を区別するには, 10 秒間の間に作成されたディ
|
||||||
|
レクトリを最大 10 個までまとめて単一のシリンダグループに書き込む
|
||||||
|
という手順が使えるでしょう. とにかく私の結論は, そろそろ実験
|
||||||
|
を始めて見る時期だろうということです.
|
||||||
|
|
||||||
|
<sect1>
|
||||||
|
<heading>カーネルパニックを最大限に利用する</heading>
|
||||||
|
|
||||||
|
<p>
|
||||||
|
<em>[この節は, freebsd-current <ref id="mailing" name="mailing
|
||||||
|
list"> に <url url="mailto:<wpaul@FreeBSD.ORG" name="Bill Paul">
|
||||||
|
が投稿したメールを, <url url="mailto:des@FreeBSD.ORG"
|
||||||
|
name="Dag-Erling Coïdan Smørgrav"> が校正し,括弧内のコ
|
||||||
|
メントを追加して引用したものです. ]</em>
|
||||||
|
|
||||||
|
<p>
|
||||||
|
<verb>
|
||||||
|
From: Bill Paul <wpaul@skynet.ctr.columbia.edu>
|
||||||
|
Subject: Re: the fs fun never stops
|
||||||
|
To: ben@rosengart.com
|
||||||
|
Date: Sun, 20 Sep 1998 15:22:50 -0400 (EDT)
|
||||||
|
Cc: current@FreeBSD.ORG
|
||||||
|
</verb>
|
||||||
|
|
||||||
|
<p>
|
||||||
|
<em>[<ben@rosengart.com> が以下のパニックメッセージを
|
||||||
|
投稿しました.]</em>
|
||||||
|
<verb>
|
||||||
|
> Fatal trap 12: page fault while in kernel mode
|
||||||
|
> fault virtual address = 0x40
|
||||||
|
> fault code = supervisor read, page not present
|
||||||
|
> instruction pointer = 0x8:0xf014a7e5
|
||||||
|
^^^^^^^^^^
|
||||||
|
> stack pointer = 0x10:0xf4ed6f24
|
||||||
|
> frame pointer = 0x10:0xf4ed6f28
|
||||||
|
> code segment = base 0x0, limit 0xfffff, type 0x1b
|
||||||
|
> = DPL 0, pres 1, def32 1, gran 1
|
||||||
|
> processor eflags = interrupt enabled, resume, IOPL = 0
|
||||||
|
> current process = 80 (mount)
|
||||||
|
> interrupt mask =
|
||||||
|
> trap number = 12
|
||||||
|
> panic: page fault
|
||||||
|
</verb>
|
||||||
|
|
||||||
|
<p>このようなメッセージが表示された場合, 問題が起きる状況を確認し
|
||||||
|
て, 情報を送るだけでは十分ではありません. 下線をつけた命令ポインタ
|
||||||
|
値は重要な値ですが, 残念ながらこの値は構成に依存します. つまり, こ
|
||||||
|
の値は使っているカーネルのイメージに依存するのです. もしスナップショッ
|
||||||
|
トなどの GENERIC カーネルを使っているのであれば, 他の人間が問題の
|
||||||
|
ある関数について追試をすることができますが, カスタマイズされたカー
|
||||||
|
ネルの場合は, 使っている本人にしか問題の起こった場所は特定できない
|
||||||
|
のです.
|
||||||
|
|
||||||
|
<p> 何をすれば良いのでしょう？
|
||||||
|
|
||||||
|
<itemize>
|
||||||
|
<item>命令ポインタ値をメモします. <tt/0x8:/ という部分は今回必
|
||||||
|
要ありません. 必要なのは <tt/0xf0xxxxxx/ という部分です.
|
||||||
|
<item>システムがリブートしたら, 以下の操作を行います:
|
||||||
|
<verb>
|
||||||
|
% nm /kernel.that.caused.the.panic | grep f0xxxxxx
|
||||||
|
</verb>
|
||||||
|
ここで, <tt/f0xxxxxx/ は命令ポインタ値です. カーネルシンボルの
|
||||||
|
テーブルは関数のエントリポイントを含み, 命令ポインタ値は,
|
||||||
|
関数内部のある点であり, 最初の点ではないため, この操作を行っても
|
||||||
|
完全に一致するものが表示されない場合もあります. この場合は,
|
||||||
|
最後の桁を省いてもういちどやってみてください. このようになりま
|
||||||
|
す:
|
||||||
|
<verb>
|
||||||
|
% nm /kernel.that.caused.the.panic | grep f0xxxxx
|
||||||
|
</verb>
|
||||||
|
これでも一致しない場合は, 桁を減らしながら何らかの出力があるま
|
||||||
|
で繰り返してください. 何か出力されたら, それがカーネルパニック
|
||||||
|
を引き起こした可能性のある関数のリストです. これは, 問題点を見付ける
|
||||||
|
正確な方法ではありませんが, 何もないよりましです.
|
||||||
|
|
||||||
|
</itemize>
|
||||||
|
|
||||||
|
<p>このようなパニックメッセージを投稿している人はよく見掛けますが,
|
||||||
|
このように, 命令ポインタ値を, カーネルシンボルテーブルの中の関数
|
||||||
|
とつき合わせて調べている人はまれです.
|
||||||
|
|
||||||
|
<p>パニックの原因を突き止める最良の方法は, クラッシュダンプをとり,
|
||||||
|
<tt/gdb(1)/ でスタックトレースを行うことです. もちろん -current
|
||||||
|
で <tt/gdb(1)/ がちゃんと動いていればですが (私は動くことを保証
|
||||||
|
できません. ELF 化された <tt/gdb(1)/ はカーネルクラッシュダンプを
|
||||||
|
正しく扱えないと言っている人がいました. 3.0 がβテストを終える前,
|
||||||
|
に調べなければいけません. さもないと CD 出荷後に大顰蹙を買うことに
|
||||||
|
なります).
|
||||||
|
|
||||||
|
<p>
|
||||||
|
どっちにしろ, 私は普通以下のようにします.
|
||||||
|
|
||||||
|
<itemize>
|
||||||
|
<item>カーネルコンフィグファイルを作ります. カーネルデバッガが
|
||||||
|
必要そうであれば options 'DDB' を加えても良いです(私は永久ルー
|
||||||
|
プが起こっていそうな場合に, ブレークポイントを設定するのに使って
|
||||||
|
います).
|
||||||
|
|
||||||
|
<item> <tt/config -g KERNELCONFIG/ としてビルドディレクトリを設
|
||||||
|
定します.
|
||||||
|
|
||||||
|
<item><tt>cd /sys/compile/KERNELCONFIG; make</tt>
|
||||||
|
<item>カーネルのコンパイルが終了するのを待ちます.
|
||||||
|
<item><tt/cp kernel kernel.debug/
|
||||||
|
<item><tt/strip -d kernel/
|
||||||
|
<item><tt/mv /kernel /kernel.orig/
|
||||||
|
<item><tt>cp kernel /</tt>
|
||||||
|
<item>reboot
|
||||||
|
</itemize>
|
||||||
|
|
||||||
|
<p> <em>[注: 現在 3.0-BETA では, <tt/strip -d/ の代りに
|
||||||
|
<tt/strip -aout -d/ を使う必要があります.]</em>
|
||||||
|
|
||||||
|
<p> 全てのデバッグシンボルを含んだカーネルを, 実際にブートする必要は
|
||||||
|
<em>ありません.</em> <tt/-g/ をつけてコンパイルされたカーネルは,
|
||||||
|
簡単に 10MB 近くの大きさになってしまいます. こんな大きなカーネル
|
||||||
|
を実際にブートする必要はありません. この大きなカーネルイメージは
|
||||||
|
後で<tt/gdb(1)/を使うときにのみ必要です(<tt/gdb(1)/ がシンボル
|
||||||
|
テーブルを必要とするため). シンボルを含んだカーネルのコピーを保
|
||||||
|
存 しておき, <tt/strip -d/ を使ってシンボルを除いたカーネルを作
|
||||||
|
成して ブートします.
|
||||||
|
|
||||||
|
<p> 確実にクラッシュダンプをとるには, <tt>/etc/rc.conf</tt> を編
|
||||||
|
集して <tt/dumpdev/ を使用しているスワップパーティションに指定す
|
||||||
|
る必 要があります. こうすると <tt/rc(8)/ スクリプトから
|
||||||
|
<tt/dumpon(8)/ コマンドが実行されクラッシュダンプ機能が有効にな
|
||||||
|
ります. 手動で <tt/dumpon(8)/ コマンドを実行してもかまいませ
|
||||||
|
ん. パニックの後, クラッシュダンプは <tt/savecore(8)/ コマンドを
|
||||||
|
使用して取り出すこと ができます. <tt/dumpdev/ が
|
||||||
|
<tt>/etc/rc.conf</tt> で設定されていれ ば, <tt/rc(8)/ スクリプト
|
||||||
|
から <tt/savecore(8)/ が自動的に実行され, クラッシュダンプを
|
||||||
|
<tt>/var/crash</tt> に保存します.
|
||||||
|
|
||||||
|
<p> 注: FreeBSD のクラッシュダンプのサイズは, ふつう物理メモリサ
|
||||||
|
イズと同じです. つまり 64MB のメモリを積んでいれば, 64MB のクラッ
|
||||||
|
シュ ダンプが生成されることになります. <tt>/var/crash</tt> に十
|
||||||
|
分な空き 容量があることを確認してください. 手動で
|
||||||
|
<tt/savecore(8)/ を実行す れば, もっと空き容量のあるディレクトリ
|
||||||
|
にクラッシュダンプを保存でき ます. <tt/options MAXMEM=(foo)/ と
|
||||||
|
いう行をカーネルコンフィグファイ ルに追加することで, カーネルの
|
||||||
|
メモリ使用量を制限できます. たとえば 128MB のメモリがある場合も,
|
||||||
|
カーネルのメモリ使用量を 16MB に制限し クラッシュダンプのサイズ
|
||||||
|
も 128MB ではなく 16MB にすることができます.
|
||||||
|
|
||||||
|
<p> クラッシュダンプを取り出せたら, 以下のように <tt/gdb(1)/ を使っ
|
||||||
|
てスタックトレースをとります:
|
||||||
|
|
||||||
|
<p>
|
||||||
|
<verb>
|
||||||
|
% gdb -k /sys/compile/KERNELCONFIG/kernel.debug /var/crash/vmcore.0
|
||||||
|
(gdb) where
|
||||||
|
</verb>
|
||||||
|
|
||||||
|
<p> 必要な情報が 1 画面に収まらないことも多いので, できれば
|
||||||
|
<tt/script(1)/ を使って出力を記録します. strip していないカーネ
|
||||||
|
ル イメージを使うことで, 全てのデバッグシンボルが参照でき, パニッ
|
||||||
|
ク の発生したカーネルのソースコードの行が表示されているはずです.
|
||||||
|
通常, 正確なクラッシュへの過程を追跡するには, 出力を最後の行から
|
||||||
|
逆方向に読まなければなりません. また <tt/gdb(1)/ を使って, 変数
|
||||||
|
や 構造体の内容を表示させ, クラッシュした時のシステムの状態を調
|
||||||
|
べられ ます.
|
||||||
|
|
||||||
|
<p> もしあなたがデバッグ狂で, 同時に別のコンピュータを利用できる
|
||||||
|
環境にあれば, <tt/gdb(1)/ をリモートデバッグに使うこともできます.
|
||||||
|
リモートデバッグを使うと, あるコンピュータ上の <tt/gdb(1)/ を使っ
|
||||||
|
て, 別のコンピュータのカーネルをデバッグできます. ブレークポイン
|
||||||
|
トの設 定, カーネルコードのステップ実行など, ふつうのプログラム
|
||||||
|
のデバッグ と変わりません. コンピュータを 2 台並べてデバッグする
|
||||||
|
チャンスには, なかなか恵まれないので, 私はまだリモートデバッグを
|
||||||
|
試したことはあり ません.
|
||||||
|
|
||||||
|
<p> <em>[Bill による注: DDB を有効にしていてカーネルがデバッガに
|
||||||
|
落ちたら, ddb のプロンプトで 'panic' と入力すれば, 強制的にパニッ
|
||||||
|
クを 起こしクラッシュダンプさせることができます. パニックの途中
|
||||||
|
で, 再び デバッガに落ちるかもしれませんが, 'continue' と入力すれ
|
||||||
|
ば, クラッシュダンプを最後まで実行させられます.]</em>
|
||||||
|
|
||||||
|
</sect>
|
||||||
|
|
|
||||||
Loading…
Reference in a new issue