iPhoneアプリのクラッシュレポートを象徴するようにしようと思っています。
iTunesConnectからクラッシュレポートを取得しました。App Storeに送信したアプリケーションバイナリと、ビルドの一部として生成されたdSYMファイルがあります。
これらのファイルはすべて、スポットライトでインデックス付けされた単一のディレクトリ内にまとめられています。
今何？
私は呼び出しを試みました：
symbolicatecrash crashreport.crash myApp.app.dSYM
クラッシュレポートにあるのと同じテキストを出力するだけで、記号化されていません。
私は何か間違ったことをしていますか？
Apple からのクラッシュ レポートを分析する手順:
アプリストアにプッシュされた release .app ファイル、リリース時に作成された .dSYM ファイル、および APPLE から受信したクラッシュ レポートをFOLDERにコピーします。
端末アプリケーションを開き、上記で作成したフォルダーに移動します (cdコマンドを使用)
実行します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 つのアセットがあります。
example.crashXCode のオーガナイザーからエクスポートされた、または iTunes Connect から受信したクラッシュ ログ ファイル自体 (つまり)。.appパッケージ (つまり) 。パッケージ (つまり)example.appがある場合は、パッケージを解凍してパッケージを抽出できます (つまり)。その後、パッケージは展開されたフォルダーに存在します。.ipaexample.ipa.app.ipaunzip example.ipa.appPayload/.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
...
この抜粋では、クラッシュ ログは、UUID を持つ example.app/example という名前のアプリ バイナリ イメージに属しています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 ディレクトリで a を実行して見つけることができます。
ご覧のとおり、これ以上パラメーターは指定されていません。そのため、スクリプトはスポットライト検索を実行して、アプリケーションのバイナリとデバッグ シンボルを見つける必要があります。という特定のインデックスでデバッグ シンボルを検索します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 を持つパッケージが提供されます。.dSYMSpotlight がパッケージを見つけられない場合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）では、クラッシュレポートをXcodeOrganizerの[DeviceLogs]セクションにドラッグアンドドロップすると、自動的に記号化されます。これは、Build＆Archive（Xcode 3.2.2の一部でもある）を使用してそのバージョンのアプリをビルドした場合に最適に機能すると思います。
XCODE 9 用に更新
任意のiOS デバイスを Mac に接続します (はい、物理的なものです。はい、これがばかげていることはわかっています)。
「ウィンドウ」メニューから「デバイス」を選択します
左側でデバイスをクリックし、右側で [デバイス ログを表示] をクリックします。
待って。表示されるまでに 1 分ほどかかる場合があります。たぶん、そうすることでCommand-AこれDeleteがスピードアップします。
文書化されていない重要な手順: iTunesConnect から取得したクラッシュ レポートの名前拡張.txt拡張機能に.crash
クラッシュ レポートを左側のその領域にドラッグします
そして、Xcode はクラッシュ レポートを象徴し、結果を表示します。
ソース: https://developer.apple.com/library/ios/technotes/tn2151/_index.html
また、シンボリッククラッシュを実行する前に、dsym、app bundle、crashlogを同じディレクトリにまとめました。
次に、.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の時点では、Developerディレクトリはありません。このユーティリティはここにあります：
/Applications/Xcode.app/Contents/SharedFrameworks/DTDeviceKitBase.framework/Versions/A/Resources/symbolicatecrash
私は自分のアプリで Airbrake を使用しています。これは、リモート エラー ログのかなり良い仕事をします。
バックトレースで必要な場合に、atos でシンボル化する方法は次のとおりです。
Xcode (4.2) でオーガナイザーに移動し、.ipa ファイルが生成されたアーカイブを右クリックします。
ターミナルで、たとえばxcarchive に cd しますMyCoolApp 10-27-11 1.30 PM.xcarchive
以下を入力してくださいatos -arch armv7 -o 'MyCoolApp.app'/'MyCoolApp'
(一重引用符を忘れないでください)
その呼び出しに自分のシンボルを含めません。得られるのは、空の行のブロック カーソルです。
次に、そのブロック カーソルにシンボル コードをコピーして貼り付け、Enter キーを押します。次のように表示されます。
-[MyCoolVC dealloc] (in MyCoolApp) (MyCoolVC.m:34)
ブロック カーソルに戻り、他の記号を貼り付けることができます。
最初のビットを再入力せずに 1 つの項目のバックトレースを実行できると、時間の節約になります。
楽しみ！
Xcode 4を使用すると、タスクはさらに簡単になります。
とvoilà。ログファイルがインポートされ、自動的にシンボル化されます。Xcode- >製品->最初にアーカイブを使用してビルドをアーカイブした場合。
Xcode 4.2.1 で、Organizerを開き、Library/Device Logsに移動して、.crash ファイルをクラッシュ ログのリストにドラッグします。数秒後にシンボル化されます。
元のビルドがアーカイブされた Xcode の同じインスタンスを使用する必要があることに注意してください (つまり、ビルドのアーカイブがOrganizerに存在する必要があります)。
魔法の Xcode オーガナイザーは、私のアプリを記号化することに関してそれほど魔法ではありません。失敗したアプリの送信から Apple から戻ってきたクラッシュ レポートのシンボルはまったくありませんでした。
コマンドラインを使用して、クラッシュ レポートを (ストアに送信した) .app ファイルと .dSYM ファイルと同じフォルダーに配置してみました。
$ symbolicatecrash "My App_date_blahblah-iPhone.crash" "My App.app"
これはアプリのシンボルのみを提供し、コア基盤コードは提供しませんでしたが、オーガナイザーが提供する数値ダンプよりも優れており、アプリで発生したクラッシュを見つけて修正するのに十分でした. Foundation シンボルを取得するためにこれを拡張する方法を誰かが知っていれば、それはありがたいです。
私の場合、クラッシュレポートをメールからオーガナイザーに直接ドラッグしていました。何らかの理由で、クラッシュレポートが象徴化されるのを防ぎました（理由を知りたいです）。
クラッシュレポートを最初にデスクトップにコピーしてから、そこからオーガナイザーにドラッグすると、適切にシンボリック化されます。
非常に特殊なケースです、私は知っています。しかし、念のために共有したいと思いました。
Airbrake を使用している人には、上記の確かな応答がありますが、微調整しないとうまくいきません。
一部のメモリアドレスでは機能しますが、他のメモリアドレスでは機能しません。理由はわかりません...
私のために働いた組み合わせは次のとおりです。
atosを使用して、クラッシュ レポートにあるアドレスとオフセットで正しいシンボル情報を解決できませんでした。これを行ってみると、より意味のあるものが表示され、正当なスタック トレースのように見えます。
これは、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\"";
symbolicatecrash スクリプトを適切に実行するには、多くのハッキングを行う必要がありました。
私が知る限り、symbolicatecrash では現在、.app が .dsym と同じディレクトリにある必要があります。.dsym を使用して .app を見つけますが、シンボルを見つけるために dsym を使用しません。
これらのパッチを試す前に、symbolicatecrash のコピーを作成して、dsym で見えるようにする必要があります。
getSymbolPathFor_dsymUuid 関数の 212 行目あたり
212 my @executablePath = grep { -e && ! -d } glob("$dsymdir" . "/Contents/Resources/DWARF/" . $executable);
matchesUUID関数の265行目あたり
265 return 1;
これは簡単です。多くの検索を行った後、クラッシュ ログ ファイル全体を象徴する明確な手順を見つけました。
幸せなコーディング、
リヤズ
すべてのクラッシュ ログを象徴するスクリプトを好みます。
フォルダを作成し、そこに 4 つのものを配置します。
symbolicatecrashperl スクリプト - その場所を示す多くの SO 回答があります
クラッシュに一致するビルドのアーカイブ (Xcode オーガナイザーから。シンプルShow in Finderにコピー) [これが必要かどうかはわかりません]
すべてのxccrashpointパッケージ - (Xcode Organizer からShow in Finder、ディレクトリ内のすべてのパッケージ、またはシンボル化する単一の xccrashpoint をコピーできます)
その短いスクリプトをディレクトリに追加します。
#!/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 つのディレクトリが作成されます。
allCrashes- すべてのクラッシュが発生しますxccrashpoint。
symboledCrashes- 同じがクラッシュしますが、すべてのシンボルが表示されます。
スクリプトを実行する前に、古いクラッシュからディレクトリを消去する必要はありません。それは自動的にきれいになります。幸運を！
クラッシュを象徴するために、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 オーガナイザーでドラッグ アンド ドロップできるように自動化できます。
まず、リモート スクリプト 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 を使用して、元のアプリのアップロード バイナリ拒否のエラーを特定するのが好きです。上記の 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 はクラッシュをシンボル化して表示することができず、「Missing dSYM」アラートが Fabric ダッシュボードに表示されます。
不足している dSYM は、以下に概説する手順に従って手動でアップロードできます。
注: 自動化された dSYM アップロード ツールの代わりに、Fabric は、プロジェクトのビルド プロセスの一部として実行するように手動で構成できるコマンドライン ツール (upload-symbols) を提供します。設定手順については、以下のアップロード シンボル セクションを参照してください。
...