Apple Developer Connection
高度な検索
Member Login ログイン | ご入会 ADC連絡先

Technical Note TN2118
カーネルコアダンプ

このテクニカルノートでは、Mac OS X 10.3以降でリモートのカーネルのコアダンプを可能にする方法について説明します。カーネルパニックまたはハングが生じた後、カーネルコアダンプでそのカーネルの状態を調べることができます。この方法で、2台のマシンによるカーネルデバッガを使えない場合に、カーネルの問題をデバッグすることができます。

このテクニカルノートは2種類の読者を対象にしています。カーネル拡張開発者は、ローカルでは再現できないカーネルパニックやハングをデバッグするために、この情報を利用できます。また、システム管理者はパニックを起こしているマシンの詳細や原因を記録したり、高可用性システムのオフラインデバッグを実行するために、この情報を利用できます。





はじめに

Mac OS Xカーネルのパニックが生じると、ユーザに重大な迷惑をかけるため、決してパニックを起こすべきではありません。そのため、カーネルパニックは、必ずアップルのコードまたはサードパーティ製カーネル拡張のコードのバグが原因です。そのようなバグは、調査して解決する必要があります。

カーネルコアダンプをキャプチャできると役立つ状況がいくつかあります。

  • カーネル拡張を作成していて、カーネルパニックに遭遇した場合は、通常、2台のマシンによるカーネルデバッガを使って問題をデバッグできます。しかし、これができない状況もあります。たとえば、(まれにしか発生しないために、または素性の知れないハードウェアや非標準的な環境でしか起こらないために)デスクトップ上で再現できない問題をテスターやエンドユーザが報告してきても、標準ツールではデバッグできません。このような場合に、パニックを起こしたカーネルのコアダンプをキャプチャし、そのコアダンプを使用してデバッグできれば便利です。

  • 多数のMacintoshコンピュータをまとめて管理している場合は、パニックを起こしているコンピュータとその原因を監視したい場合も考えられます。コアダンプの情報を使用すると、カーネルパニックが発生する頻度、何らかの共通の症状があるかどうか、そして最も重要なことですが、サードパーティ製カーネル拡張が関与しているかどうかを知ることができます。

  • 最後に、高可用性のMacintoshサーバを管理していて、サーバパニックに関して問題がある場合は、カーネルコアダンプをキャプチャして、すぐにサーバを再起動し、問題をオフラインでデバッグできます。

このような状況にあるユーザを支援するために、アップルはMac OS X 10.3にリモートカーネルコアダンプ機能を導入しました。マシンでパニックが発生すると、TCP/IP を利用してカーネルのコアダンプをサーバに伝送するように、Mac OS Xコンピュータを設定できます。コアダンプサーバは、クライアントからカーネルコアダンプを回収して、ディスクに書き込むデーモンです。その後、さまざまなツール、とりわけGDBを使用してコアダンプを分析できます。

重要:カーネルコアダンプは現在のところ、インテルベースのMacintoshコンピュータでは機能しません(r. 4267969)

重要:カーネルコアダンプクライアントは、Mac OS X 10.3以降のカーネルに組み込まれています。また、カーネルコアダンプサーバ、kdumpdは、Mac OS X10.3以降にはデフォルトでインストールされています。

カーネルコアダンプサーバのソースは、Darwinnetwork_cmdsプロジェクト内)に含まれています。このサーバを他のUNIX系のプラットフォーム(初期バージョンのMac OS Xを含む)に移植することは可能ですが、そうした試みについてはこのテクニカルノートでは触れません。

このテクニカルノートで説明するのは、カーネルコアダンプサーバをセットアップする方法、およびサーバにダンプするように別のコンピュータを設定する方法についてです。また、セットアップをテストする方法についても説明します。最後に、大部分はカーネル拡張の開発者向けですが、結果のカーネルコアダンプを使用してデバッグを行う方法について説明します。

先頭に戻る

サーバの設定

カーネルコアダンプを取得する第一歩は、カーネルコアダンプサーバをセットアップすることです。まず、次の点を考慮しながら、サーバとして使用するマシンを選びます。

  • カーネルコアダンプサーバは、高価なコンピュータでなくてもかまいません。Mac OS Xを実行できるものであれば、どのようなマシンでも容易に動作します。

  • カーネルコアダンプは大きく、一般的に100 MB台になります(クライアントのカーネルマップサイズ、物理メモリサイズ、利用パターンなどによって異なります)。サーバには、大量の空きディスクスペースを確保してください。

  • また、サーバには静的 IP アドレスを設定する必要があります。

  • サーバのIPアドレスは、すべてのクライアントに見えなければなりません。サーバをNATまたはファイアウォールの背後に置くには、クライアントがサーバと同じNATまたはファイアウォールの背後にある必要があります。

警告:セットアッププロセスを簡素化するために、このテクニカルノートでは、クライアントとサーバが信頼できるネットワーク上にあり、そのサーバでアカウントを持っているすべてのユーザを信頼することを前提としています。そのため、より危険性のある環境では、一部のセットアップ手順(ワールド書き込み可能な/PanicDumpsディレクトリの作成など)は適当ではありません。

また、クライアントでパニックが発生すると、カーネルメモリの内容がそのままサーバに送信されます。このデータに機密情報が含まれている可能性は十分にあります。このデータが権限のない人に覗かれないように、ネットワークを構成してください(スイッチハブ、ファイアウォール、またはVPNなどを使用)。

注:カーネルダンププロトコルはポート1069でUDPを使用します。現在のところ、この設定は変更できません。

カーネルコアダンプサーバを使用可能にするには、次の手順を実行します。

コアダンプディレクトリの作成

まず、サーバがコアダンプを書き込むディレクトリを作成する必要があります。リスト1に、これを/PanicDumpsディレクトリに設定する方法の一例を示します。ディレクトリをワールド書き込み可能にする必要があります。サーバプロセスはnobodyとして実行されるため、ワールド書き込み可能にしないとディレクトリを変更できないからです。

リスト1:コアダンプディレクトリの作成

server$ mkdir /PanicDumps
server$ chmod ugo+wx /PanicDumps

重要:以降では、カーネルコアダンプを保存するために、/PanicDumpsディレクトリを使用するものとします。このステップで別のディレクトリを使用する場合は、以降のステップでは、/PanicDumpsを当該ディレクトリのフルパスに置き換えてください。

xinetdの設定

次のステップでは、クライアントの接続時にサーバを実行するxinetd (extended Internet services daemon)を設定します。そのためには、リスト2のテキストを/etc/xinetd.dディレクトリのmacosxkdumpというファイルにコピーします。リスト3 に、それを行う方法の1つを示します。

リスト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

重要:システムセキュリティを維持するには、設定ファイル(/etc/xinetd.d/macosxkdump)に、リスト3の最後のコマンドに示したアクセス権を設定してください。

xinetdへのシグナル送信

設定の変更を反映するには、SIGHUPシグナルをxinetdデーモンに送信する必要があります。リスト4にその方法を示します。最初のコマンドを入力するときには、単一引用符(ASCII 39)ではなく、必ずバッククォート(ASCII 96)を使用してください。

リスト4:xinetdへのシグナル送信

server$ sudo kill -HUP `cat /var/run/xinetd.pid`
Password: ********

あるいは、単にマシンを再起動するだけでも、xinetdに新しい設定が反映されます。

設定の確認

すべてが正しく設定されていることを確認するには、次のどちらかの方法をとります。

  • システムログを見ると、リスト5に示すテキストに似たテキストがあるのが分かります。これは、xinetdが新しいサービスを開始したことを示します。システムログは手動か(/var/log/system.log)、「コンソール」アプリケーションで表示できます。

  • SIGUSR1シグナルをxinetdに送信すると、現在の設定をダンプするよう要求できます。リスト 6にその方法を示します。デーモンは情報を/var/run/xinetd.dumpに追加します。リスト7のように、macosxkdumpサービスがアクティブであることを示すレコードがあります。

リスト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つの引数を含むようにboot-argsオープンファームウェア変数を変更する必要があります。

  • debug引数の0×0400フラグをセットしなければなりません。さらに、この引数には便利なフラグがいくつかありますが、これについては後で詳述します。

  • _panicd_ip引数にカーネルコアダンプサーバのIPアドレスを設定する必要があります。ドット区切りの10進表記のIPv4アドレスを使用する必要があります。IPv6とDNSアドレスはサポートされていません。

リスト8には、カーネルコアダンプサーバのIPアドレスが10.0 .40 .2であると仮定して、boot-argsオープンファームウェア変数を設定する方法の一例を示します。

リスト8:boot-argsオープンファームウェア変数の設定

client$ sudo nvram boot-args="debug=0xd44 _panicd_ip=10.0.40.2"
Password: ********

この設定を反映するには再起動する必要があります。

重要:boot-argsオープンファームウェア変数は、ソフトウェアアップデートを含め、新しいシステムソフトをインストールした場合と、「システム環境設定」を使って起動ディスクを変更した場合に必ずリセットされます。

デバッグフラグの詳細

boot-argsデバッグフラグを使用すると、カーネルデバッグのさまざまな面をコントロールできます。これらのフラグの多くは、既存のドキュメンテーションに文書化されています。表1に、カーネルコアダンプを生成するときに便利な3つの古いフラグに加えて、Mac OS X 10.3で新たに導入されたフラグの説明を示します。表2では、これらのフラグを組み合わせて、便利な振る舞いを実現する方法を示します。

表1:デバッグフラグ

シンボル名フラグ新規説明
DB_NMI0x0004×NMI(コンピュータ前面のプログラマスイッチ。お使いのコンピュータにプログラマスイッチがない場合は、テクニカルQ&Aの QA1264「Generating an NMI Without a Programmer's Switch」を参照)のサポートを含め、カーネルデバッグ機能をアクティブにします。
DB_ARP0x0040×カーネルデバッガnubによるARPの使用を可能にすることで、サブネット内でのデバッグをサポートします。一般に、カーネルコアダンプを取得するときにはこのフラグを有効にします。
DB_LOG_PI_SCRN0x0100×グラフィカルなパニック画面を無効にします。通常、カーネルコアダンプの送信状況を見られるように、カーネルコアダンプを使用可能にする際に、このフラグをセットします。
DB_KERN_DUMP_ON_PANIC0x0400システムでパニックが発生したときに、カーネルにコアダンプさせます。
DB_KERN_DUMP_ON_NMI0x0800ユーザがNMIをトリガしたときに、カーネルにコアダンプさせます。
DB_DBG_POST_CORE0x1000NMI (DB_KERN_DUMP_ON_NMI)に応えてコアをダンプした後のカーネルの振る舞いをコントロールします。ユーザがNMIをトリガした場合、このフラグがクリアされていると、カーネルはコアをダンプして続行します。逆に、このフラグがセットされていると、カーネルはコアをダンプして、デバッガ接続を待ちます。
DB_PANICLOG_DUMP0x2000カーネルがフルコアをダンプするか(フラグをクリアした場合)、単にパニックログをダンプするか(フラグをセットした場合)をコントロールします。

表2:デバッグフラグの便利な組合せ

シナリオ
0x00442台のマシンによる日常的なデバッグに使用します。DB_NMIにより、NMIをトリガしてカーネルデバッガに入れます。DB_ARPにより、永続ARPテーブルエントリをいじらなくてもデバッグが可能です。
0x0444カーネルコアダンプのキャプチャに使用します。カーネルデバッグをアクティブにするために、DB_NMIをオンにします。前述のとおり、DB_ARPもオンにします。DB_KERN_DUMP_ON_PANICはカーネルコアダンプ機能をアクティブにします。
0x2444カーネルパニックログのキャプチャに使用します。他のフラグは前記のとおりにセットしますが、DB_PANICLOG_DUMPは、カーネルにコアダンプではなく、パニックログを生成させるためにセットします。
0x0844ユーザから不可解なカーネルレベルのフリーズの報告があるときに役立ちます。フリーズが発生したときに、ユーザがNMIをトリガすると、システムがカーネルコアダンプを生成して続行します。この場合は効果がないため、DB_LOG_PI_SCRNをセットする必要はありません。
0x0d44カーネルコアダンプ機能のテストに役立ちます。この設定では、パニックが発生するか、ユーザがNMIをトリガすると、カーネルコアダンプが生成されます。DB_LOG_PI_SCRNをセットするのは、カーネルコアダンプの送信状況を確認できるようにするためです。

先頭に戻る

インタフェースの選択

デフォルトでは、システムはカーネルコアダンプなど、カーネルデバッグに内蔵Ethernetポートを使用します。これは、Xserve G5のように2つの内蔵Ethernetポートがあるマシンでは、問題を引き起こすことがあります(r. 3844652)。システムに特定のポートを使用させるには、kdp_match_nameブート引数を設定します。たとえば、システムがカーネルデバッグに「en0」を常時使用するように設定するには、boot-args設定にkdp_match_name=en0を追加します。

先頭に戻る

設定のテスト

サーバを使用可能にして、クライアントを設定したら、それらが期待どおり機能することを確認する必要があります。システムをテストするには、カーネルパニックをトリガする必要があります。これを簡単にするために、このテクニカルノートにはInstantPanicという簡単なカーネル拡張を掲載しました。これはロードするとすぐに、カーネルパニックを引き起こします。このカーネル拡張のソースとバイナリは、「ダウンロード」セクションから入手できます。

まず、このカーネル拡張をデスクトップにダウンロードして解凍してください。次に、リスト9に示すコマンドを使用して、このカーネル拡張をロードします。

リスト9:'InstantPanic'カーネル拡張のロード

client$ cd ~/Desktop/InstantPanic/build/
client$ sudo cp -r InstantPanic.kext /
Password: ********
client$ sudo kextload /InstantPanic.kext

注:リスト9では、正しいファイルパーミッションを持っていることを保証するために、rootとして(sudoを使用)カーネル拡張のコピーを作成します。不正なファイルパーミッションでは、カーネル拡張をロードできません。KEXTが不正であるというメッセージをkextloadが出力する場合は、sudo chown -R root:wheel /InstantPanic.kextを使用してパーミッションを修正できます。

リスト9のコマンドを実行すると、クライアントマシンでパニックが生じます。次に、順当に行けば、クライアントがカーネルコアダンプをサーバに送信します。クライアントの画面に送信状況が表示されます(DB_LOG_PI_SCRNデバッグフラグをセットした場合)。転送が完了すると、サーバで/PanicDumpsディレクトリをリスト表示して、新しいパニックダンプファイルを確認できます。

リスト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

このファイルの名前には、カーネルのバージョン(uname -aで表示。この場合は517)、クライアントのIPアドレス(10.0.40.7)、および固有のタイムスタンプが含まれています。

注:この名前には、カーネルのマイナーバージョンは含まれていません。これは将来のシステムリリースで解決される既知の問題です(r. 3735061)。

次のセクションでは、このファイルを使用してカーネルパニックをデバッグする方法について説明します。あるいは、DB_PANICLOG_DUMPフラグをセットすると、/PanicDumpsディレクトリにパニックログファイルが格納されます。このファイルは、パニック後に/Library/Logsに格納されるファイルに似ています。リスト11にその一例を示します。

リスト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」を参照してください。

先頭に戻る

カーネルコアダンプを利用したデバッグ

カーネルプログラマであれば、カーネルコアダンプを使用して、カーネルパニックとハングをデバッグできます。始める前に、以下の有用なリソースを集めてください。

  • パニックを起こしたカーネルのKernel Debug Kit。Kernel Debug KitはアップルデベロッパWebサイトから入手できます。

    このセクションでは、お使いのマシンに正しいKernel Debug Kitディスクイメージがマウントされているものと仮定しています。

  • パニックを起こしたカーネルのDarwinソースコード。Darwinソースコードは、アップルデベロッパサイトのDarwinページから入手できます。カーネルのソースはxnuプロジェクトに含まれています。

    Darwinのカーネルソースは、Mac OS Xカーネルの構築に使用されたソースとほとんど同じです。ほとんどすべての場合に、Darwinのソースを使用して、Mac OS Xカーネルの有用なソースレベルデバッグを行えます。

    このセクションでは、パニックを起こしたマシンで、xnu-517に対応するMac OS X 10.3が稼動しているものと仮定しています。さらに、xnu-517ソースをダウンロードして、デスクトップ上のxnu-517というフォルダに解凍してあるものとします。

重要:クライアントマシン(パニックを起こしたマシン)のカーネルのバージョンに対応するリソースをダウンロードしてください。

カーネルコアファイルを使ったデバッグの第一歩は、GDBで-cオプションを使用して当該ファイルを開くことです。リスト12にその一例を示します。GDBでコアファイルを開くと、標準のGDBコマンドを使用してカーネルの状態を調べられます。この例では、btを使ってスタックのバックトレースを表示します。

リスト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では、-c引数に指定するパス名にスペースを使用できません(r. 3727326)。このバグはXcode 1.5以降では修正されています。

このように、このバックトレースにはシンボル情報が含まれていません。これは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はディレクトリ/SourceCache/xnu/xnu-517にカーネルのソースがあるものとします。シンボリックリンクを適切に使用すれば、その想定を満たせます。リスト14に、このリンクを作成する方法を示します。

リスト14:GDBがソースを見つけられるようにシンボリックリンクを作成

server$ mkdir -p /SourceCache/xnu
server$ ln -s ~/Desktop/xnu-517 /SourceCache/xnu

これで、スタックを遡り(frameコマンドを使用)、実際のソースコードリストを表示できます(listコマンドを使用)。リスト15にその一例を示します。

リスト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つを実行する方法を示します。

  • paniclogは標準的なパニック情報を出力します。

  • showallstacksは、カーネル内で動作しているあらゆるスレッドのバックトレースを出力します。

リスト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を参照してください。

注:switchtoactおよびswitchtoactマクロは、カーネルコアファイルが対象の場合には正しく機能しません(r. 3401283)。代わりに、switchtocorethreadおよびresetcorectxマクロを使用してください。これらのマクロは、Mac OS X 10.4バージョンのGDBを使用する必要がありますが、初期のシステムが生成するカーネルコアダンプにも使用できます。

これらのマクロを現行バージョンのGDBで使用するには(r. 3836595)、switchtocorethreadを実行する前に次のコマンドを入力します。

set $lr = 0

先頭に戻る

まとめ

カーネルコアダンプ機能は、カーネル拡張開発者と大規模で複雑なMacintosh設備を有するユーザの両方に役立つデバッグツールです。この機能を使用すると、2台のマシンによるカーネルデバッガを利用できない場合にも、カーネルパニック(およびカーネルハング)に関する情報を取得できます。

先頭に戻る

参考資料

先頭に戻る

ダウンロード

先頭に戻る

ドキュメント改訂履歴

日付メモ
2006-02-17/PanicDumpsのパーミッションに関して説明。switchtocorethreadマクロとkdp_match_nameブート引数について記述。いくつかのリンク切れを修正。
2004-11-12mkdir -pを使って1つのコマンドでSourceCacheパスを作成。paniclogカーネルデバッグマクロについて記述。/tmpにmacosxkdumpの作業用コピーを置く。起動ディスクの変更によってもブート引数がリセットされるという注記。DB_NMIを説明する表項目にQ&A 1264への参照を追加。
2004-08-19リモートカーネルコアダンプを取得し使用する方法を説明。

掲載日: 2006-02-17




Did this document help you?
Yes: Tell us what works for you.

It’s good, but: Report typos, inaccuracies, and so forth.

It wasn’t helpful: Tell us what would have helped.