次の方法で共有

ラボ 1.2 クラッシュのトラブルシューティング - lldb デバッガーでシステムによって生成されたコア ダンプ ファイルを分析する

適用対象: .NET Core 2.1、.NET Core 3.1、.NET 5

この記事では、Linux で lldb デバッガーをインストールして構成し、システムで生成された .NET Core ダンプ ファイルを開いて分析する方法について説明します。

前提条件

これらのトラブルシューティング ラボに従う必要がある最小要件は、低 CPU および高 CPU パフォーマンスの問題を示すために ASP.NET Core アプリケーションを用意することです。

インターネット上でこの目標を達成するためのいくつかのサンプル アプリケーションを見つけることができます。 たとえば、 Microsoft の単純な webapi サンプルをダウンロードして設定し 望ましくない動作を示すことができます。 または、サンプル プロジェクトとして、BuggyAmb ASP.NET Core アプリケーションを使用できます。

このシリーズの前の部分に従っている場合は、次のセットアップを準備しておく必要があります。

  • Nginx は、次の 2 つの Web サイトをホストするように構成されています。
    • 1 つ目は、 myfirstwebsite ホスト ヘッダー (http://myfirstwebsite) を使用して要求をリッスンし、ポート 5000 でリッスンするデモ ASP.NET Core アプリケーションに要求をルーティングします。
    • 2 つ目は、 buggyamb ホスト ヘッダー (http://buggyamb) を使用して要求をリッスンし、ポート 5001 でリッスンする 2 番目の ASP.NET Core サンプル バグのあるアプリケーションに要求をルーティングします。
  • ASP.NET コア アプリケーションは、サーバーが再起動されたとき、またはアプリケーションが応答を停止したときに自動的に再起動するサービスとして実行されている必要があります。
  • Linux ローカル ファイアウォールが有効になっており、SSH トラフィックと HTTP トラフィックを許可するように構成されています。

Note

セットアップの準備ができていない場合は、「Part 2 Core アプリ ASP.NET 作成して実行する」に進みます。

このラボを続行するには、Nginx の背後で実行されているコア Web アプリケーション ASP.NET 少なくとも 1 つの問題がある必要があります。

このラボの目標

この記事は、Linux 上の ASP.NET Core アプリケーションのクラッシュをデバッグするための 2 つのラボ パーツの 2 番目です。

Lab 1.1 でクラッシュの問題を再現してトラブルシューティングしますクラッシュの問題を再現する手順に従い、トラブルシューティングを開始しました。 Nginx とシステム ログを確認し、メモリ ダンプ ファイルを収集して分析してトラブルシューティングに進んだ。 Ubuntu のコア ダンプ ファイル マネージャーである apport によって生成されたクラッシュ コア ダンプ ファイルを抽出しました。

このパートでは、SOS という名前の .NET Core デバッガー拡張機能と連携するように lldb デバッガーをインストールして構成し、lldb でダンプ ファイルを開いて分析します。

lldb をインストールする

このラボでは、lldb 3.9 以降のバージョンをインストールする必要があります。 いくつかの Linux ディストリビューションの手順については、 Linux での LLDB のインストールに関する記事を参照してください。 このセクションでは、 apt インストール コマンド ( sudo apt install lldb) を使用することをお勧めします。 次のスクリーンショットでは、lldb-6.0 が一部の依存関係と共にインストールされていることがわかります。

sudo コマンドのスクリーンショット。

インストールが完了したら、コア ダンプ ファイルを開いたときに SOS を自動的に読み込むことができるように lldb を構成する必要があります。

lldb の構成

lldb でコア ダンプ ファイルを開く前に、次の必要な手順に従ってシンボル パスを設定し、シンボルをダウンロードし、lldb を開いたときに自動的に SOS を読み込みます。

  1. dotnet-symbol ツールをインストールします。

    dotnet tool install -g dotnet-symbol

  2. ターゲット ダンプ ファイルのシンボルをダウンロードします。

    dotnet-symbol <path_of_dump_file>

  3. SOS をインストールします。

    1. dotnet-sos グローバル ツールをインストールします。

      dotnet tool install -g dotnet-sos

    2. SOS をインストールします。

      dotnet-sos install

dotnet-symbol ツールをインストールする

前のパートでは、dotnet-symbol ツールと dotnet-dump ツールと dotnet-gcdump ツールを既にインストールしておく必要があります。 これらのツールをまだインストールしていない場合は、先に進む前にインストールしてください。 これを行うには、 dotnet tool install -g dotnet-symbol コマンドを実行して dotnet-symbols をインストールします。 まだインストールしていない場合は、dotnet-dump と dotnet-gcdump をインストールします。 次のスクリーンショットに示すように、3 つのツールがインストールされているはずです。

list コマンドのスクリーンショット。

ダンプ ファイルのシンボルをダウンロードする

パート 1では、apport レポートからコア ダンプ ファイルをアンパックする方法を指示されました。 次に、シンボル ファイルをダウンロードします。 この アーティクルで説明されているように、シンボルは高レベルで動作します。 ソース コードとバイナリの間のマッピングとして機能します。 これらのマッピングは、デバッガーが呼び出し履歴を読み取るときに、関数名またはメソッド名、ソース行情報、またはローカル変数名を解決するために使用されます。

dotnet-symbol ~/dumps/dotnet/CoreDump -o ~/dumps/symbols --host-only コマンドを使用して、メモリ ダンプ ファイルのシンボルを ~/dumps/symbols ディレクトリにダウンロードします。

dumps コマンドのスクリーンショット。

--host-only スイッチを追加しない場合、シンボル ファイルをダウンロードすると、"HTTP 404 が見つかりません" というエラー メッセージが表示されることがあります。 これらのメッセージは無視してかまいません。 --host-only パラメーターは、ホスト プログラムのみをダウンロードします。 これは、lldb が ASP.NET Core アプリケーションのデバッグを開始するために必要なすべてです。

次の手順では、SOS で管理されるデバッグ拡張機能をインストールします。 これにより、分析を実行するために必要な .NET デバッグ コマンドが公開されます。

SOS のインストール

SOS とは 非公式のドキュメントによると SOS はデバッガー拡張機能であり、開発者は ASP.NET Core などの .NET アプリケーションのマネージド状態を調べることができます。.NET WPF や .NET Windows フォームなどの NET ベースのアプリケーション。 SOS は、Windows 上の WinDbg デバッガーまたは cdb デバッガー、Linux および macOS 上の lldb によって読み込むことができるクロスプラットフォーム拡張機能です。

SOS をインストールするには、まず次の dotnet-sos ツールをインストールする必要があります。

dotnet tool install -g dotnet-sos

次に、SOS をインストールします。

dotnet-sos install

次のスクリーンショットは、正常にインストールされた結果を示しています。 デバッガーの起動時に SOS 拡張機能が自動的に読み込まれるように、dotnet-sos ツールによって lldb デバッガーが構成されていることに注意してください。

install コマンドのスクリーンショット。

これで、lldb を使用してダンプ ファイルを開く準備ができました。

lldb でコア ダンプを開く

コア ダンプを開くには、lldb と次の構文を使用する必要があります。

lldb --core <dump path> <host-program>

<host-program>は、.NET Core アプリケーションを起動したネイティブ プログラムです。 アプリケーションが自己完結型でない限り、これは通常 dotnet です。 これが自己完結型アプリケーションの場合、この変数は、 .dll 拡張子のないアプリケーションの名前です。

同じフォルダー名を使用してフォローしていると仮定すると、前のセクションで生成したメモリ ダンプ ファイルへのパスは ~/dumps/dotnet/CoreDump にする必要があります。 したがって、 lldb --core ~/dumps/dotnet/CoreDump を実行してファイルを開きます。

次のスクリーンショットは、メモリ ダンプ ファイルを開いた lldb デバッガーを示しています。

lldb コマンドのスクリーンショット。

シンボルを設定する

~/dumps/symbols ディレクトリの dotnet-symbol コマンドを使用してシンボル ファイルをダウンロードしたことを思い出してください。 デバッガー内で実行する必要がある最初のコマンドは、シンボル のダウンロード用に設定したディレクトリにシンボル サーバー のパスを設定することです。

setsymbolserver -directory ~/dumps/symbols

次に、シンボルを読み込みます。 loadsymbols

loadsymbols コマンドのスクリーンショット。

lldb コマンドと SOS コマンドを実行する

lldb コマンドがいくつかあります。 これらは、 help コマンドを使用して一覧表示できます。 この一覧では、SOS コマンド ユーザー定義コマンドにも表示されます。 SOS は lldb のプラグインです。 同じ help コマンドを使用して、プラグインのヘルプ情報を取得できます。

Note

lldb の出力を時々クリアしたい場合があります。 これを行うには、 Ctrl + L キーを押します。

開始するには、 bt ("バック トレース") コマンドを使用して、スレッドのネイティブ呼び出し履歴を確認します。 このコマンドは、アクティブなスレッドの呼び出し履歴を示します。

bt コマンドのスクリーンショット。

次に、SOS clrstack コマンドを使用してマネージド呼び出し履歴を調べます。

clrstack コマンドのスクリーンショット。

情報を取得することはできません。 報告されたスタックが不完全であるため、スタック ウォークは失敗します。 これは、前に説明した内容に関連しています。自動生成されたコア ダンプ ファイルでは、すべてのマネージド状態を収集することはできません。

また、例外が発生したためにプロセスがクラッシュしたことを思い出してください。 SOS pe コマンドを実行して、例外情報を確認します。

pe コマンドのスクリーンショット。

出力でわかるように、 pe コマンドは、現在のスレッドでスローされた最後の例外 (存在する場合) に関する情報を表示します。

この場合の例外メッセージは 一時的に使用できません。 ただし、例外の種類と関数名は解決されません。 代わりに、値は unknown として示されます。

例外のアドレスも表示されます。 pe コマンドでこのアドレスをパラメーターとして渡して、詳細が使用可能かどうかを確認できます。 次に、pe 00007F8244048538 を実行します。

Note

このコマンドでは、アドレスをダンプ ファイルに表示されているアドレスに置き換えます。

コマンドの unknow 例外の種類のスクリーンショット。

スタックで参照されているオブジェクトを表示する場合でも、 unknownと同じ値が表示されます。

dso コマンドのスクリーンショット。

スタック上のオブジェクトの 1 つのアドレスを選択し、 dumpobj <address> コマンドを使用してオブジェクトを確認することで、詳細情報の取得を試みることができます。

dumpobj コマンドのスクリーンショット。

ただし、このコマンドは、より多くの不明なメッセージのみを返すので、効果も制限されると結論付ける可能性があります。 次に、自動生成されたダンプ ファイルの操作を停止します。 exit コマンドを実行して lldb セッションを終了します。

要約すると、システムによって生成されたダンプ ファイルによっていくつかの情報が提供されますが、重要な情報がまだ不足しています。 次のパートでは、クラッシュ ダンプをキャプチャするための推奨される方法について説明します。

次のステップ

ラボ 1.3 クラッシュの問題のトラブルシューティング - createdump ツールを使用してコア クラッシュ ダンプをキャプチャする