はじめにMac OS Xカーネルのパニックが生じると、ユーザに重大な迷惑をかけるため、決してパニックを起こすべきではありません。そのため、カーネルパニックは、必ずアップルのコードまたはサードパーティ製カーネル拡張のコードのバグが原因です。そのようなバグは、調査して解決する必要があります。 カーネルコアダンプをキャプチャできると役立つ状況がいくつかあります。
このような状況にあるユーザを支援するために、アップルはMac OS X 10.3にリモートカーネルコアダンプ機能を導入しました。マシンでパニックが発生すると、TCP/IP を利用してカーネルのコアダンプをサーバに伝送するように、Mac OS Xコンピュータを設定できます。コアダンプサーバは、クライアントからカーネルコアダンプを回収して、ディスクに書き込むデーモンです。その後、さまざまなツール、とりわけGDBを使用してコアダンプを分析できます。 重要:カーネルコアダンプは現在のところ、インテルベースのMacintoshコンピュータでは機能しません(r. 4267969)。 重要:カーネルコアダンプクライアントは、Mac OS X 10.3以降のカーネルに組み込まれています。また、カーネルコアダンプサーバ、 カーネルコアダンプサーバのソースは、Darwin( このテクニカルノートで説明するのは、カーネルコアダンプサーバをセットアップする方法、およびサーバにダンプするように別のコンピュータを設定する方法についてです。また、セットアップをテストする方法についても説明します。最後に、大部分はカーネル拡張の開発者向けですが、結果のカーネルコアダンプを使用してデバッグを行う方法について説明します。 サーバの設定カーネルコアダンプを取得する第一歩は、カーネルコアダンプサーバをセットアップすることです。まず、次の点を考慮しながら、サーバとして使用するマシンを選びます。
警告:セットアッププロセスを簡素化するために、このテクニカルノートでは、クライアントとサーバが信頼できるネットワーク上にあり、そのサーバでアカウントを持っているすべてのユーザを信頼することを前提としています。そのため、より危険性のある環境では、一部のセットアップ手順(ワールド書き込み可能な また、クライアントでパニックが発生すると、カーネルメモリの内容がそのままサーバに送信されます。このデータに機密情報が含まれている可能性は十分にあります。このデータが権限のない人に覗かれないように、ネットワークを構成してください(スイッチハブ、ファイアウォール、またはVPNなどを使用)。 注:カーネルダンププロトコルはポート1069でUDPを使用します。現在のところ、この設定は変更できません。 カーネルコアダンプサーバを使用可能にするには、次の手順を実行します。 コアダンプディレクトリの作成まず、サーバがコアダンプを書き込むディレクトリを作成する必要があります。リスト1に、これを リスト1:コアダンプディレクトリの作成 server$ mkdir /PanicDumps server$ chmod ugo+wx /PanicDumps 重要:以降では、カーネルコアダンプを保存するために、 xinetdの設定次のステップでは、クライアントの接続時にサーバを実行する リスト2:'macosxkdump'設定ファイルの内容
service macosxkdump
{
disable = no
type = UNLISTED
socket_type = dgram
protocol = udp
port = 1069
user = nobody
groups = yes
server = /usr/libexec/kdumpd
server_args = /PanicDumps
wait = yes
}
リスト3:'macosxkdump'ファイルの作成
server$ cat > /tmp/macosxkdump
service macosxkdump
{
disable = no
type = UNLISTED
socket_type = dgram
protocol = udp
port = 1069
user = nobody
groups = yes
server = /usr/libexec/kdumpd
server_args = /PanicDumps
wait = yes
}
^D
server$ ls -l /tmp/macosxkdump
-rw-r--r-- 1 quinn staff 278 14 Jul 15:25 /tmp/macosxkdump
server$ sudo cp /tmp/macosxkdump /etc/xinetd.d
Password: ********
server$ ls -l /etc/xinetd.d/macosxkdump
-rw-r--r-- 1 root wheel 278 14 Jul 15:26 /etc/xinetd.d/macosxkdump
重要:システムセキュリティを維持するには、設定ファイル( xinetdへのシグナル送信設定の変更を反映するには、 リスト4:xinetdへのシグナル送信 server$ sudo kill -HUP `cat /var/run/xinetd.pid` Password: ******** あるいは、単にマシンを再起動するだけでも、 設定の確認すべてが正しく設定されていることを確認するには、次のどちらかの方法をとります。
リスト5:システムログ情報 Jul 14 15:40:57 localhost xinetd[349]:Starting reconfiguration Jul 14 15:40:57 localhost xinetd[349]:readjusting service ssh Jul 14 15:40:57 localhost xinetd[349]:Reconfigured:new=1 old=1 dropped=0 (services) リスト6:設定をダンプするシグナルをxinetdに送信 server$ sudo kill -USR1 `cat /var/run/xinetd.pid` Password: ******** リスト7:xinetdのダンプの確認
Service = macosxkdump
State = Active
Service configuration: macosxkdump
id = macosxkdump
flags = IPv4
type = UNLISTED
socket_type = dgram
Protocol (name,number) = (udp,17)
port = 1069
wait = yes
user = -2
Groups = yes
PER_SOURCE = -1
Bind = All addresses.
Server = /usr/libexec/kdumpd
Server argv = kdumpd /PanicDumps
Only from: All sites
No access: No blocked sites
Logging to syslog. Facility = daemon, level = info
Log_on_success flags = HOST PID HOST
Log_on_failure flags = HOST
running servers = 0
retry servers = 0
attempts = 0
service fd = 6
サーバを正しく設定したら、次のステップへ進んで、クライアントを設定します。 クライアントの設定クライアントマシンでカーネルコアダンプを使用可能にするには、2つの引数を含むように
リスト8には、カーネルコアダンプサーバのIPアドレスが10.0 .40 .2であると仮定して、 リスト8:boot-argsオープンファームウェア変数の設定 client$ sudo nvram boot-args="debug=0xd44 _panicd_ip=10.0.40.2" Password: ******** この設定を反映するには再起動する必要があります。 重要: デバッグフラグの詳細
表1:デバッグフラグ
表2:デバッグフラグの便利な組合せ
インタフェースの選択デフォルトでは、システムはカーネルコアダンプなど、カーネルデバッグに内蔵Ethernetポートを使用します。これは、Xserve G5のように2つの内蔵Ethernetポートがあるマシンでは、問題を引き起こすことがあります(r. 3844652)。システムに特定のポートを使用させるには、 設定のテストサーバを使用可能にして、クライアントを設定したら、それらが期待どおり機能することを確認する必要があります。システムをテストするには、カーネルパニックをトリガする必要があります。これを簡単にするために、このテクニカルノートにはInstantPanicという簡単なカーネル拡張を掲載しました。これはロードするとすぐに、カーネルパニックを引き起こします。このカーネル拡張のソースとバイナリは、「ダウンロード」セクションから入手できます。 まず、このカーネル拡張をデスクトップにダウンロードして解凍してください。次に、リスト9に示すコマンドを使用して、このカーネル拡張をロードします。 リスト9:'InstantPanic'カーネル拡張のロード client$ cd ~/Desktop/InstantPanic/build/ client$ sudo cp -r InstantPanic.kext / Password: ******** client$ sudo kextload /InstantPanic.kext 注:リスト9では、正しいファイルパーミッションを持っていることを保証するために、rootとして( リスト9のコマンドを実行すると、クライアントマシンでパニックが生じます。次に、順当に行けば、クライアントがカーネルコアダンプをサーバに送信します。クライアントの画面に送信状況が表示されます( リスト10:カーネルコアダンプの例 server$ ls -l /PanicDumps total 216872 -rw-rw---- 1 nobody admin 111038464 14 Jul 17:43 core-xnu-517-10.0.40.7-e58299ec このファイルの名前には、カーネルのバージョン( 注:この名前には、カーネルのマイナーバージョンは含まれていません。これは将来のシステムリリースで解決される既知の問題です(r. 3735061)。 次のセクションでは、このファイルを使用してカーネルパニックをデバッグする方法について説明します。あるいは、 リスト11:パニックログファイルの例
server$ ls -l /PanicDumps
total 216872
-rw-rw---- 1 nobody staff 738 14 Jul 10:53 paniclog-xnu-517-10.0.40.7-74da81e2
server$ cat paniclog-xnu-517-10.0.40.7-74da81e2
panic(cpu 0): InstantPanic: Just add water!
Latest stack backtrace for cpu 0:
Backtrace:
0x000833B8 0x0008389C 0x0001ED8C 0x144ED038 0x144ED0E0 \
0x0007FE28 0x00080094 0x0003CF6C
0x00021650 0x0001BCD0 0x0001C0D8 0x00093D58 0x006D0069
Kernel loadable modules in backtrace (with dependencies):
com.apple.dts.kext.InstantPanic(1.0)@0x144ec000
Proceeding back via exception chain:
Exception state (sv=0x1C8C3280)
PC=0x900075C8; MSR=0x0200F030; DAR=0x144ED19C; DSISR=0x40000000; \
LR=0x90007118; R1=0xBFFFF410; XCP=0x00000030 (0xC00 - System call)
Kernel version:
Darwin Kernel Version 7.0.0:
Wed Sep 24 15:48:39 PDT 2003; root:xnu/xnu-517.obj~1/RELEASE_PPC
カーネルパニックログの詳細については、テクニカルノートの TN2063「Understanding and Debugging Kernel Panics」を参照してください。 カーネルコアダンプを利用したデバッグカーネルプログラマであれば、カーネルコアダンプを使用して、カーネルパニックとハングをデバッグできます。始める前に、以下の有用なリソースを集めてください。
重要:クライアントマシン(パニックを起こしたマシン)のカーネルのバージョンに対応するリソースをダウンロードしてください。 カーネルコアファイルを使ったデバッグの第一歩は、GDBで リスト12:GDBでカーネルコアファイルを開く server$ gdb -c /PanicDumps/core-xnu-517-10.0.40.7-e58299ec GNU gdb 5.3-20030128 (Apple version gdb-309) (Thu Dec 4 15:41:30 GMT 2003) Copyright 2003 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB.Type "show warranty" for details. This GDB was configured as "powerpc-apple-darwin". unable to read unknown load command 0x0 #0 0x00083a3c in ?? () (gdb) bt #0 0x00083a3c in ?? () #1 0x00083a3c in ?? () #2 0x14406038 in ?? () #3 0x144060e0 in ?? () #4 0x0007fe28 in ?? () #5 0x00080094 in ?? () #6 0x0003cf6c in ?? () #7 0x00021650 in ?? () #8 0x0001bcd0 in ?? () #9 0x0001c0d8 in ?? () #10 0x00093d58 in ?? () #11 0x003e0045 in ?? () 注:Xcode 1.2以前のGDBでは、 このように、このバックトレースにはシンボル情報が含まれていません。これはKernel Debug Kitからカーネルシンボルをロードすることで変更できます。リスト13にその一例を示します。カーネルシンボルをロードすると、バックトレースはずっと役立ちます。 リスト13:カーネルシンボルのロード (gdb) add-symbol-file /Volumes/KernelDebugKit/mach_kernel add symbol table from file "/Volumes/KernelDebugKit/mach_kernel"?(y or n) y Reading symbols from /Volumes/KernelDebugKit/mach_kernel...done. (gdb) bt #0 Debugger (message=0x2952a0 "panic") at /SourceCache/xnu/xnu-517/osfmk/ppc/model_de… #1 0x0001ed8c in panic (str=0x2952a0 "panic") at /SourceCache/xnu/xnu-517/osfmk/kern/… #2 0x0001ed8c in panic (str=0x1440616c "InstantPanic:Just add water!") at /SourceCac… #3 0x14406038 in ?? () #4 0x144060e0 in ?? () #5 0x0007fe28 in kmod_start_or_stop (id=339763600, start=339763600, data=0x105dd2c, d… #6 0x00080094 in kmod_control (host_priv=0xd9b000, id=1143226596, flavor=1, data=0x10… #7 0x0003cf6c in _Xkmod_control (InHeadP=0x105dd10, OutHeadP=0x10bb110) at mach/host_… #8 0x00021650 in ipc_kobject_server (request=0x2e0000) at /SourceCache/xnu/xnu-517/os… #9 0x0001bcd0 in mach_msg_overwrite_trap (msg=0xbffff450, option=17161488, send_size=… #10 0x0001c0d8 in mach_msg_trap (msg=0xd9b000, option=165072, send_size=1, rcv_size=0,… #11 0x00093d58 in .L_kernel_syscall () #12 0x003e0045 in zombproc () シンボルが利用できるようになれば、ソースレベルデバッグまではあと少しです。バックトレースのフレーム1から分かるように、GDBはディレクトリ リスト14:GDBがソースを見つけられるようにシンボリックリンクを作成 server$ mkdir -p /SourceCache/xnu server$ ln -s ~/Desktop/xnu-517 /SourceCache/xnu これで、スタックを遡り( リスト15:ソースレベルデバッグ
(gdb) frame 1
#1 0x0001ed8c in panic (str=0x2952a0 "panic") at /SourceCache/xnu/xnu-517/osfmk/kern/…
198 * Release panicwait indicator so that other cpus may call Debugger().
(gdb) list
193 _doprnt(str, &listp, consdebug_putc, 0);
194 va_end(listp);
195 kdb_printf("\n");
196
197 /*
198 * Release panicwait indicator so that other cpus may call Debugger().
199 */
200 panicwait = 0;
201 Debugger("panic");
202 /*
最後に、これも重要ですが、実行中のカーネルの場合と同じように、カーネルコアダンプを対象にカーネルデバッグマクロを使用できます。リスト16に、カーネルデバッグマクロをロードして、最も有用なマクロのうちの2つを実行する方法を示します。
リスト16:カーネルデバッグマクロの実行
(gdb) source /Volumes/KernelDebugKit/kgmacros
Loading Kernel GDB Macros package. Type "help kgm" for more info.
(gdb) paniclog
panic(cpu 0): InstantPanic: Just add water!
Latest stack backtrace for cpu 0:
Backtrace:
0x000833B8 0x0008389C 0x0001ED8C 0x14421038 0x144210E0 \
0x0007FE28 0x00080094 0x0003CF6C
0x00021650 0x0001BCD0 0x0001C0D8 0x00093D58 0x00700070
Kernel loadable modules in backtrace (with dependencies):
com.apple.dts.kext.InstantPanic(1.0)@0x14420000
Proceeding back via exception chain:
Exception state (sv=0x1C926500)
PC=0x900075C8; MSR=0x0200F030; DAR=0x1442119C; DSISR=0x40000000; \
LR=0x90007118; R1=0xBFFFF410; XCP=0x00000030 (0xC00 - System call)
Kernel version:
Darwin Kernel Version 7.0.0:
Wed Sep 24 15:48:39 PDT 2003; root:xnu/xnu-517.obj~1/RELEASE_PPC
(gdb) showallstacks
[...]
task vm_map ipc_space #acts pid proc command
0x00c94980 0x009438dc 0x00c866b0 1 384 0x00e28a08 kextload
activation thread pri state wait_queue wait_event
0x00d9b000 0x00d9b000 26 R
kernel_stack=0x076d8000
stacktop=0x076dbb30
0x076dbb30 0x83a3c <Debugger+524>
0x076dbbb0 0x1ed8c <panic+472>
0x076dbc30 0x14406038
0x076dbc80 0x144060e0
0x076dbcd0 0x7fe28 <kmod_start_or_stop+224>
0x076dbd40 0x80094 <kmod_control+128>
0x076dbda0 0x3cf6c <_Xkmod_control+256>
0x076dbe00 0x21650 <ipc_kobject_server+284>
0x076dbe50 0x1bcd0 <mach_msg_overwrite_trap+2992>
0x076dbf20 0x1c0d8 <mach_msg_trap+28>
0x076dbf70 0x93d58 <.L_mach_return>
0x076dbfc0 0x3e0045 <com.apple.driver.AppleI2C + 0x4045>
stackbottom=0x076dbfc0
カーネルデバッグマクロの詳細については、I/O Kit documentationを参照してください。 注: これらのマクロを現行バージョンのGDBで使用するには(r. 3836595)、
まとめカーネルコアダンプ機能は、カーネル拡張開発者と大規模で複雑なMacintosh設備を有するユーザの両方に役立つデバッグツールです。この機能を使用すると、2台のマシンによるカーネルデバッガを利用できない場合にも、カーネルパニック(およびカーネルハング)に関する情報を取得できます。 参考資料
ダウンロード
ドキュメント改訂履歴
掲載日: 2006-02-17 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|