iPhoneアプリのクラッシュレポートの象徴

iPhoneアプリのクラッシュレポートを象徴的に表示するようにしています。

iTunes Connectからクラッシュレポートを取得しました。App Storeに送信したアプリケーションバイナリと、ビルドの一部として生成されたdSYMファイルがあります。

これらのファイルはすべて、スポットライトによってインデックスが付けられた単一のディレクトリ内に一緒にあります。

今何？

私は呼び出してみました：

symbolicatecrash crashreport.crash myApp.app.dSYM

また、最初はクラッシュレポートにあるのと同じテキストが出力されるだけで、シンボリックではありません。

私は何か間違ったことをしていますか？

アップルからのクラッシュレポートを分析する手順：

1. appstoreにプッシュされたリリースの.appファイル、リリース時に作成された.dSYMファイル、およびクラッシュレポートがAPPLEからFOLDERにコピーされます。

2. 端末アプリケーションを開き、上で作成したフォルダーに移動します（cdコマンドを使用）

3. を実行しますatos -arch armv7 -o APPNAME.app/APPNAME MEMORY_LOCATION_OF_CRASH。メモリの場所は、レポートに従ってアプリがクラッシュした場所である必要があります。

例： atos -arch armv7 -o 'APPNAME.app'/'APPNAME' 0x0003b508

これにより、クラッシュの原因となった正確な行、メソッド名が表示されます。

例： [classname functionName:]; -510

IPAの象徴

シンボリック化にIPAを使用する場合-拡張子.ipaの名前を.zipに変更して抽出すると、アプリを含むペイロードフォルダーを取得できます。この場合、.dSYMファイルは必要ありません。

注意

これは、アプリのバイナリにシンボルが削除されていない場合にのみ機能します。デフォルトでは、ビルドはシンボルを取り除きます。プロジェクトのビルド設定「コピー中のデバッグシンボルのストリップ」でNOに変更できます。

詳細はこの投稿を参照してください

クラッシュログを象徴するためにこれらのすべての回答を読んだ後（そして最後に成功しました）、ここで欠落しているいくつかのポイントが、symbolicatecrashの呼び出しが象徴的な出力を生成しない理由を判断するために非常に重要だと思います。

クラッシュログをシンボル化するときに、3つのアセットを組み合わせる必要があります。

1. example.crashXCodeのオーガナイザーからエクスポートされた、またはiTunes Connectから受け取ったクラッシュログファイル自体（つまり）。
2. .appパッケージ（すなわちexample.app、それ自体がクラッシュログに属するアプリのバイナリが含まれていること）。あなたが持っている場合.ipa（つまり、パッケージをexample.ipa）その後、抽出することができます.app解凍したパッケージを.ipaパッケージ（すなわちunzip example.ipa）。その後、.appパッケージは解凍されたPayload/フォルダーに存在します。
3. .dSYMデバッグシンボルを含むパッケージ（つまりexample.app.dSYM）

シンボリック化を開始する前に、これらのすべてのアーティファクトが一致するかどうかを確認する必要があります。つまり、クラッシュログは使用しているバイナリに属し、デバッグシンボルはそのバイナリのビルド中に生成されたものです。

各バイナリは、クラッシュログファイルで確認できるUUIDによって参照されます。

...
Binary Images:
0xe1000 -    0x1f0fff +example armv7  <aa5e633efda8346cab92b01320043dc3> /var/mobile/Applications/9FB5D11F-42C0-42CA-A336-4B99FF97708F/example.app/example
0x2febf000 - 0x2fedffff  dyld armv7s  <4047d926f58e36b98da92ab7a93a8aaf> /usr/lib/dyld
...

この抽出では、クラッシュログはexample.app/exampleという名前のアプリバイナリイメージとUUIDに属していますaa5e633efda8346cab92b01320043dc3。

dwarfdumpを使用して、バイナリパッケージのUUIDを確認できます。

dwarfdump --uuid example.app/example
UUID: AA5E633E-FDA8-346C-AB92-B01320043DC3 (armv7) example.app/example

その後、デバッグシンボルがそのバイナリに属しているかどうかを確認する必要があります。

dwarfdump --uuid example.app.dSYM
UUID: AA5E633E-FDA8-346C-AB92-B01320043DC3 (armv7) example.app.dSYM/Contents/Resources/DWARF/example

この例では、すべてのアセットが適合しており、スタックトレースをシンボル化できるはずです。

進むとsymbolicatecrashスクリプト：

Xcode 8.3では、次の方法でスクリプトを呼び出すことができます。

/Applications/Xcode.app/Contents/SharedFrameworks/DVTFoundation.framework/Versions/A/Resources/symbolicatecrash -v example.crash 2> symbolicate.log

そこにない場合find . -name symbolicatecrashは、Xcode.appディレクトリでを実行して検索できます。

ご覧のとおり、指定されたパラメーターはありません。したがって、スクリプトはスポットライト検索を実行して、アプリケーションのバイナリとデバッグシンボルを見つける必要があります。と呼ばれる特定のインデックスでデバッグシンボルを検索しますcom_apple_xcode_dsym_uuids。この検索は自分で行うことができます。

mdfind 'com_apple_xcode_dsym_uuids = *'

それぞれ。

mdfind "com_apple_xcode_dsym_uuids == AA5E633E-FDA8-346C-AB92-B01320043DC3"

最初のスポットライトの呼び出しでは、すべてのインデックス付きdSYMパッケージが提供され、2番目のスポットライト.dSYMでは、特定のUUIDを持つパッケージが提供されます。Spotlightが.dSYMパッケージを見つけられない場合symbolicatecrash、どちらも見つかりません。たとえば、~/Desktopスポットライトのサブフォルダーでこのすべてを行うと、すべてを見つけることができるはずです。

symbolicatecrashあなたの.dSYMパッケージが見つかった場合、次のような行があるはずですsymbolicate.log：

@dsym_paths = ( <SOME_PATH>/example.app.dSYM/Contents/Resources/DWARF/example )

.appパッケージを見つけるために、次のようなスポットライト検索がによって呼び出されsymbolicatecrashます。

mdfind "kMDItemContentType == com.apple.application-bundle && (kMDItemAlternateNames == 'example.app' || kMDItemDisplayName == 'example' || kMDItemDisplayName == 'example.app')"

パッケージがsymbolicatecrash見つかった場合は.app、次の抽出が含まれているはずですsymbolicate.log。

Number of symbols in <SOME_PATH>/example.app/example: 2209 + 19675 = 21884
Found executable <SOME_PATH>/example.app/example
-- MATCH

これらのリソースがすべて見つかったsymbolicatecrash場合は、クラッシュログのシンボリックバージョンを出力する必要があります。

そうでない場合は、dSYMおよび.appファイルを直接渡すことができます。

symbolicatecrash -v --dsym <SOME_PATH>/<App_URI>.app.dSYM/<APP_NAME>.app.dsym <CRASHFILE> <SOME_OTHER_PATH>/<APP_NAME>.app/<APP_NAME> > symbolicate.log

注：シンボリックバックトレースは、ではなくターミナルに出力されsymbolicate.logます。

最新バージョンのXcode（3.2.2）では、クラッシュレポートをXcode OrganizerのDevice Logsセクションにドラッグアンドドロップすると、自動的にシンボリック表示されます。これは、ビルドとアーカイブ（Xcode 3.2.2の一部でもある）を使用してアプリのそのバージョンをビルドした場合に最適に機能すると思います

次の手順を使用して、これを成功させました。

ステップ1：デスクトップにフォルダーを作成し、「CrashReport」という名前を付けて、3つのファイル（「MYApp.app」、「MyApp.app.dSYM」、「MYApp_2013-07-18.crash」）を入れます。

ステップ2： Finderを開いて、アプリケーションに移動します。Xcodeアプリケーションが見つかります。これを右クリックし、[パッケージの内容を表示]をクリックします。この後、この単純なパスに従います。「コンテンツ->開発者->プラットフォーム-> iPhoneOS.platform->開発者-> ライブラリ -> PrivateFrameworks-> DTDeviceKit.framework- >バージョン-> A->リソース」

または

「コンテンツ->開発者->プラットフォーム-> iPhoneOS.platform->開発者-> ライブラリ -> プライベートフレームワーク -> DTDeviceKitBase.framework- >バージョン-> A->リソース」

または

Xcode 6以降の場合、パスはApplications / Xcode.app / Contents / SharedFrameworks / DTDeviceKitBase.framework / Versions / A / Resourcesです。

「symbolicatecrash」ファイルが見つかったら、これをコピーして「CrashReport」フォルダに貼り付けます。

ステップ3：ターミナルを起動し、次の3つのコマンドを実行します

1. cd / Users / mac38 / Desktop / CrashReportと入力してEnterボタンを押します

2. DEVELOPER_DIR = "/ Applications / Xcode.app / Contents / Developer"をエクスポートしてEnterキーを押します

3. ./symbolicatecrash -A -v MYApp_2013-07-18.crash MyApp.app.dSYMを押してEnter Now it Doneを押します。

XCodeを使用して自動的にクラッシュレポートを表す手順：

Xcode 9用に更新

1. 任意の iOSデバイスをMacに接続します（物理的なデバイスです。そうです、これは愚かです）

2. 「ウィンドウ」メニューから「デバイス」を選択します

3. 左側でデバイスをクリックし、右側でデバイスログを表示します

4. 待つ。表示されるまでに1分ほどかかる場合があります。多分Command-AそれからDeleteこれをスピードアップするでしょう。

5. 文書化されていない重要なステップ： iTunesConnectから取得したクラッシュレポートの名前を.txt拡張から.crash拡張に変更する

6. クラッシュレポートを左側のその領域にドラッグします

そして、Xcodeはクラッシュレポートを象徴し、結果を表示します。

出典：https : //developer.apple.com/library/ios/technotes/tn2151/_index.html

私は自分のアプリでAirbrakeを使用しています。これは、リモートエラーログのかなり良い仕事をします。

バックトレースで必要な場合に、これらをatosで記号化する方法は次のとおりです。

1. Xcode（4.2）でオーガナイザーに移動し、.ipaファイルの生成元のアーカイブを右クリックします。

2. ターミナルで、たとえばxcarchiveにcd します。MyCoolApp 10-27-11 1.30 PM.xcarchive

3. 次のように入力しますatos -arch armv7 -o 'MyCoolApp.app'/'MyCoolApp' （一重引用符を忘れないでください）

4. その呼び出しには自分のシンボルを含めません。得られるのは、空の行にあるブロックカーソルです。

5. 次に、そのブロックカーソルにシンボルコードをコピーして貼り付け、Enterキーを押します。次のようなものが表示されます。

   -[MyCoolVC dealloc] (in MyCoolApp) (MyCoolVC.m:34)

6. ブロックカーソルに戻り、他の記号を貼り付けることができます。

最初のビットを再入力せずに1つのアイテムのバックトレースを通過できることは、時間を節約するのに役立ちます。

楽しい！

また、シンボルクラッシュを実行する前に、dsym、app bundle、およびクラッシュログを同じディレクトリにまとめました

次に、.profileで定義されたこの関数を使用して、symbolicatecrashの実行を簡略化します。

function desym
{
    /Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKit.framework/Versions/A/Resources/symbolicatecrash -A -v $1 | more
}

そこで追加された議論はあなたを助けるかもしれません。

次のコマンドを実行して、スポットライトがdysmファイルを「認識」していることを確認できます。

mdfind 'com_apple_xcode_dsym_uuids = *'

ディレクトリにあるdsymを探します。

注：最新のXcode以降、開発者ディレクトリはなくなりました。このユーティリティはここにあります：

/Applications/Xcode.app/Contents/SharedFrameworks/DTDeviceKitBase.framework/Vers‌ ions / A / Resources / symbolicatecrash

xcode 6.1.1の単純で更新された答え。

手順

1.Xcode>ウィンドウ>デバイス。

2. [デバイス]セクションのデバイスリストからデバイスを選択します。

3. [デバイスログの表示]を選択します。

4. [すべてのログ]セクションで、レポートを直接ドラッグアンドドロップできます。クラッシュ

5.Xcodeは自動的にクラッシュレポートを示します。

シンボリッククラッシュレポートは、クラッシュレポートで言及されている日付/時刻と日付/時刻を一致させることで見つけることができます。

私は数年前にアプリを開発していましたが、これは初めてのバイナリデバッグであり、すべてのファイルがどこにあるかを理解する完全なNOOBのように感じました。つまり、*。app * .dSYMとクラッシュログの場所はどこですか？私はそれを理解するために複数の投稿を読む必要がありました。写真は千の言葉の価値があり、この投稿が将来的に他の人を助けることを願っています。

1-最初にitunesconnectに移動し、クラッシュログをダウンロードします。注：ほとんどの場合、「レポートを表示するために送信されたレポートが少なすぎます。」基本的に、十分な数のユーザーがクラッシュログレポートをAppleに送信していない場合、その時点ではほとんど何もできません。

2-バイナリをAppleに送信してからコードを変更していない場合は、そのプロジェクトのXcodeを起動し、[製品]-> [アーカイブ]を再度実行します。それ以外の場合は、最新の送信済みバイナリを見つけて右クリックします。

Xcode 4.2.1でオーガナイザを開き、ライブラリ/デバイスログに移動して、.crashファイルをクラッシュログのリストにドラッグします。数秒後に表示されます。

元のビルドがアーカイブされたXcodeの同じインスタンスを使用する必要があることに注意してください（つまり、ビルドのアーカイブはOrganizerに存在している必要があります）。

Xcode 4を使用すると、タスクはさらに簡単になります。

• オープン主催、
• ライブラリをクリックします| 左側の列にあるデバイスログ
• 画面下部の「インポート」ボタンをクリックします...

そして、ボイラ。ログファイルがインポートされ、自動的にシンボル表示されます。Xcode- > Product-> Archiveを使用してビルドをアーカイブした場合。

不思議なXcode Organizerは、私のアプリのシンボル化についてそれほど不思議ではありません。アプリの送信に失敗してAppleから戻ってきたというクラッシュレポートには、まったく記号がありませんでした。

コマンドラインを使用して、クラッシュレポートを.appファイル（ストアに送信したもの）と.dSYMファイルと同じフォルダーに入れてみました。

$ symbolicatecrash "My App_date_blahblah-iPhone.crash" "My App.app"

これは私のアプリにシンボルのみを提供し、コアのファウンデーションコードを提供しませんでしたが、オーガナイザーが提供する数値ダンプよりも優れており、アプリが持つクラッシュを見つけて修正するのに十分でした。これを拡張してFoundationシンボルを取得する方法を知っている人がいれば、感謝します。

私の場合、クラッシュレポートをMailからOrganizerに直接ドラッグしていました。何らかの理由で、それがクラッシュレポートのシンボリック化を妨げていました（理由を知りたいです）。

最初にクラッシュレポートをデスクトップにコピーしてから、そこからオーガナイザーにドラッグすると、正しくレポートされます。

非常に特殊なケースです。しかし、念のため共有したいと思いました。

これは、symbolicatecrashで発生する別の問題です。バンドルにスペースがあるアプリ（つまり、「Test App.app」）では機能しません。注：送信時に名前にスペースを含めることはできないので、とにかくこれらを削除する必要がありますが、分析が必要なクラッシュが既にある場合は、symbolicatecrash（4.3 GM）にパッチを適用します。

240c240
<         my $cmd = "mdfind \"kMDItemContentType == com.apple.application-bundle && kMDItemFSName == $exec_name.app\"";
---
>         my $cmd = "mdfind \"kMDItemContentType == com.apple.application-bundle && kMDItemFSName == '$exec_name.app'\"";
251c251
<             my $cmd = "find \"$archive_path/Products\" -name $exec_name.app";
---
>             my $cmd = "find \"$archive_path/Products\" -name \"$exec_name.app\"";

Airbrakeを使用している人にとっては、上記の確かな反応がありますが、調整しないとうまくいきません。

一部のメモリアドレスで機能しますが、他のメモリアドレスでは機能しません。理由はわかりません...

• デスクトップまたはどこにでも新しいディレクトリを作成する
• Xcodeオーガナイザーで問題のアーカイブを見つける
• ファインダーに表示するにはダブルタップします
• バンドルのコンテンツを表示するにはダブルタップします
• .dSYMファイルと.appファイルを新しいディレクトリにコピーします
• 新しいディレクトリに移動
• 次のコマンドを実行します：atos -arch armv7 -o 'Vimeo.app' / 'Vimeo'
• 端末はインタラクティブな動きに入ります
• メモリアドレスに貼り付けてEnterキーを押すと、メソッド名と行番号が出力されます
• または、次のコマンドを入力します。atos -arch armv7 -o 'Vimeo.app' / 'Vimeo' 1つのアドレスのみの情報を取得するには

私にとってうまくいった組み合わせは：

1. クラッシュレポートがあったディレクトリにdSYMファイルをコピーします。
2. アプリを含むipaファイルを解凍します（ 'unzip MyApp.ipa'）
3. 結果の展開されたペイロードから、アプリケーションバイナリをクラッシュレポートおよびシンボルファイルと同じフォルダーにコピーします（「MyApp.app/MyApp」のようなもの）
4. Xcodeのオーガナイザー内からクラッシュレポートをインポートまたは再記号化する

atosを使用して、クラッシュレポートにあるアドレスとオフセットで正しいシンボル情報を解決できませんでした。これを行ったところ、もっと意味のあることがわかりました。これは正当なスタックトレースのようです。

正しく動作させるために、symbolicatecrashスクリプトを何度もハッキングする必要がありました。

私の知る限り、symbolicatecrashを実行するには、.appが.dsymと同じディレクトリにある必要があります。.dsymを使用して.appを検索しますが、dsymを使用してシンボルを検索しません。

これらのパッチを試す前に、symboliccrashのコピーを作成して、dsymで見えるようにする必要があります。

getSymbolPathFor_dsymUuid関数の212行目

212     my @executablePath = grep { -e && ! -d } glob("$dsymdir" . "/Contents/Resources/DWARF/" . $executable);

matchesUUID関数の265行目

265             return 1;

これは簡単です。たくさん検索したところ、クラッシュログファイル全体を象徴する明確な手順が見つかりました。

• .app、crash_report、およびDSYMファイルをフォルダーにコピーします。
• デバイスをxcodeに接続する
• 次に、ウィンドウに移動->デバイスを選択->デバイスログを表示
• 次に、このデバイスを選択し、すべてのログを削除します。
• クラッシュをデバイスログセクションにドラッグアンドドロップします。自動的にクラッシュを示します。レポートを右クリックしてエクスポートします。

幸せなコーディング、
リヤズ

私はすべてのクラッシュログを象徴するスクリプトを好みます。

前提条件

フォルダを作成し、そこに4つのものを配置します。

1. symbolicatecrash perlスクリプト-場所であることを伝える多くのSO回答があります

2. クラッシュに一致するビルドのアーカイブ（Xcode Organizerから。単純なas Show in Finderおよびコピー）[これが必要かどうかはわかりません]

3. すべてのxccrashpointパッケージ-（Xcode Organizerから。Show in Finderディレクトリ内のすべてのパッケージ、またはシンボリック化する単一のxccrashpointをコピーできます）

4. その短いスクリプトをディレクトリに追加します。

   #!/bin/sh
   
   echo "cleaning old crashes from directory"
   rm -P *.crash
   rm -P *.xccrashpoint
   rm -r allCrashes
   echo "removed!"
   echo ""
   echo "--- START ---"
   echo ""
   
   mkdir allCrashes
   mkdir symboledCrashes
   find `ls -d *.xccrashpoint` -name "*.crash" -print -exec cp {} allCrashes/ \;
   
   cd allCrashes
   for crash in *.crash; do
       ../symbolicatecrash $crash > ../symboledCrashes/V$crash
   done
   cd ..
   
   echo ""
   echo "--- DONE ---"
   echo ""

スクリプト

スクリプトを実行すると、2つのディレクトリが作成されます。

1. allCrashes-すべてのクラッシュがすべて発生しますxccrashpoint。

2. symboledCrashes -同じクラッシュですが、すべてのシンボルが含まれています。

3. スクリプトを実行する前に、古いクラッシュからディレクトリをクリーンアップする必要はありません。自動的にクリーニングされます。幸運を！

提案された代替案のほとんどが最新のXCode（Xcode 10でテスト済み）では機能しないことがわかりました。たとえば、Xcode-> Organizer-> Device logs -viewで.crashログをドラッグアンドドロップすることができませんでした。

Symbolicatorツールの使用をお勧めしますhttps://github.com/agentsim/Symbolicator

• GitクローンSymbolicatorリポジトリーおよびXcodeでコンパイルおよび実行
• .crashファイル（asciiファイル、ファイルの先頭にスタックトレースがある）およびクラッシュしたリリースの.xarchiveを同じ一時フォルダーにコピーします
• .crashファイルをDockのSymbolicatorアイコンにドラッグアンドドロップ
• 5〜30秒で、シンボリッククラッシュファイルが.crashおよび.xarchiveと同じフォルダーに作成されます。

クラッシュを象徴するために、Spotlightは、Appleに送信したバイナリと同時に生成された.dSYMファイルを見つけることができる必要があります。シンボル情報が含まれているため、入手できない場合は運が悪くなります。

ここでは何も「動作しない」ように見えるという事実について少し不機嫌になったので、調査を行った結果は次のとおりです。

設定：レポートを受信するQuincyKitバックエンド。私がそれを機能させるために私がやろうとしていることを彼らが示唆していることを理解することさえできなかったので、シンボリックは設定されていませんでした。

修正：サーバーからクラッシュレポートをオンラインでダウンロードします。それらは「クラッシュ」と呼ばれ、デフォルトで〜/ Downloads /フォルダーに移動します。このことを念頭に置いて、このスクリプトは「正しいこと」を行い、クラッシュレポートはXcode（オーガナイザ、デバイスログ）に送られ、シンボリック化が行われます。

スクリプト：

#!/bin/bash
# Copy crash reports so that they appear in device logs in Organizer in Xcode

if [ ! -e ~/Downloads/crash ]; then 
   echo "Download a crash report and save it as $HOME/Downloads/crash before running this script."
   exit 1
fi

cd ~/Library/Logs/CrashReporter/MobileDevice/
mkdir -p actx # add crash report to xcode abbreviated
cd actx

datestr=`date "+%Y-%m-%d-%H%M%S"`

mv ~/Downloads/crash "actx-app_"$datestr"_actx.crash"

QuincyKit / PLCRを使用する場合、2つのことを実行することで、Xcode Organizerでドラッグアンドドロップできる場所に自動化できます。

まず、リモートスクリプトadmin / actionapi.php〜line 202を編集する必要があります。タイムスタンプが正しくないように見えるため、ファイルはXcodeが認識しない「crash」という名前で終了します（何かが必要です）ドットクラッシュ）：

header('Content-Disposition: attachment; filename="crash'.$timestamp.'.crash"');

次に、iOS側でQuincyKit BWCrashReportTextFormatter.m〜line 176に変更@"[TODO]"し@"TODO"て、不正な文字を回避します。

atosは廃止されているため、OSX 10.9以降を実行している場合は、実行する必要がある場合があります。

xcrun atos

警告：/ usr / bin / atosは移動中であり、将来のOS Xリリースから削除される予定です。Xcode開発者ツールで利用できるようになりました：xcrun atos

Textwranglerを使用して、元のアプリアップロードのバイナリ拒否のエラーを特定します。（クラッシュデータはitun​​esConnectアカウントにあります。）上記のSachinの方法を使用して、original.crashをTextWranglerにコピーしてから、作成したsymbolicatecrashファイルを別のTextWranglerファイルにコピーします。2つのファイルを比較すると、違いが正確にわかります。symbolicatecrashファイルには、ファイルと問題の行番号を示す違いがあります。

私たちはクラッシュログを監視するためにGoogle Crashlyticsを使用しています。この感覚は非常にタイムリーで便利です。

ドキュメントリンク：https : //docs.fabric.io/apple/crashlytics/missing-dsyms.html#missing-dsyms

欠落しているdSYMのすべてについてFabricには、プロジェクトのdSYMを自動的にアップロードするツールが含まれています。このツールは、/ runスクリプトを通じて実行されます。このスクリプトは、オンボーディングプロセス中にスクリプト実行ビルドフェーズに追加されます。ただし、固有のプロジェクト構成のため、またはアプリでビットコードを使用しているために、dSYMアップロードが失敗する場合があります。アップロードが失敗すると、Crashlyticsはクラッシュを象徴して表示できなくなり、「dSYMがありません」というアラートがファブリックダッシュボードに表示されます。

不足しているdSYMは、以下に概説する手順に従って手動でアップロードできます。

注：自動化されたdSYMアップロードツールの代わりに、Fabricはコマンドラインツール（upload-symbols））を提供しています。これは、プロジェクトのビルドプロセスの一部として実行するように手動で構成できます。設定手順については、以下のアップロードシンボルのセクションをご覧ください。

...