アプリのアドホック バージョンからの .crash ログがあり、symbolicatecrash がシンボリック化を拒否しています。AppleがXCode 3.2.6でスクリプトを壊した後、symbolicatecrashの「die」コマンドを削除するために.patchをすでに適用しました。Symbolicatecrash は、他のクラッシュ ログでは機能しましたが、これをシンボル化することを拒否しています。私のアドホック アプリはビルドされ、「アーカイブされたアプリケーション」に保存されているため、XCode がそれを見つけられない理由はありません。.app ファイルと .dSYM ファイルを .crash ログのすぐ隣にコピーしました。サイコロはありません。
symobolicatecrash が特定の .app および .dsym ファイルを使用するように強制する方法はありますか?
クラッシュ ログに関連付けられているビルドを誤って削除してしまったことが判明しました。symbolicatecrash は、次のロジックを使用して、クラッシュ ログに関連付けられているシンボルがあるかどうかを判断します。
すべてのクラッシュ ログの下部には、バイナリ イメージのリストがあります。あなたのが最初に表示されます。バイナリ イメージに関連付けられた GUID があります。例えば：
0x1000 - 0x2befff +MyApp armv7 <a95274a309d73458a40cb5a6fd317a1c> /var/mobile/Applications/91884634-DA1A-4BDB-9E1E-6F487D8F25D7/MyApp.app/MyApp
関連する GUID は次のとおりです。 a95274a309d73458a40cb5a6fd317a1c
次に、ファイル システム内のファイルに関連付けられたメタデータを調べるツール mdfind を使用して、その GUID の大文字とハイフンでつながれた形式を探します。
アーカイブされたアプリケーションから、MyApp.app.dSYM をクリックし、[情報を取得] をクリックして、[詳細情報] を表示すると、dSYM UUID と 2 つの GUID が一覧表示されます。2 番目の GUID は関連するものです。次の形式になります。
A95274A3-09D7-3458-A40C-B5A6FD317A1C
2 番目の GUID が .crash ファイル内の GUID と一致する場合、シンボリケート クラッシュは検出してシンボリケートできます。それらが一致しない場合、それは間違ったバイナリです。
乾杯、エリック
この回答は、最新の XCode 5.1.1 に必要なものであることがわかりました。
最近、アドホック ビルドのクラッシュ ログがありました。XCode はシンボル化を拒否しました。数時間前にアーカイブされたビルドがあり、アーカイブされたビルドを使用してシンボリケーションを強制したいと考えていました。これが私がやった方法です：
1) まず、ターミナル ウィンドウを開き、アーカイブを含むディレクトリに移動しました。このコマンドを実行しました：
xcrun dwarfdump --uuid Example.app/Example | tr '[:upper:]' '[:lower:]' | tr -d '-'
これにより、アーカイブされたビルドの dsym_uuid が抽出されました。tr コマンドは、GUID をダッシュ付きの大文字の GUID からダッシュなしの小文字の GUID に変換します。
2) .crash ファイルに移動し、クラッシュ ログ内のバイナリに関連付けられている GUID を、マシンの xcdarchive に関連付けられている GUID に変更しました。
たとえば、
0x80000 - 0x49efff +MyApp armv7 <aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa> /var/mobile/Applications/DC23BDC0-75E3-4DCA-8AC3-099889CE22E0/MyApp.app/MyApp
に
0x80000 - 0x49efff +MyApp armv7 <bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb> /var/mobile/Applications/DC23BDC0-75E3-4DCA-8AC3-099889CE22E0/MyApp.app/MyApp
3) 端末から、DEVELOPER_DIR 環境変数を次のように設定しました。
export DEVELOPER_DIR=/Applications/XCode.app/Contents/Developer
4) 最後に、次のコマンドを実行しました。
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKitBase.framework/Versions/A/Resources/symbolicatecrash -v MyApp.crash /Users/me/Library/Developer/Xcode/Archives/2013-05-31/MyApp\ 5-31-13\ 7.00\ PM.xcarchive/Products/Applications/MyApp.app
XCode の新しいバージョンでは、symbolicatecrash へのパスが次のように変更されることに注意してください。
/Applications/Xcode6.app/Contents/SharedFrameworks/DTDeviceKitBase.framework/Versions/A/Resources/symbolicatecrash
このコマンドは、持っている .crash ファイルを使用して、アーカイブに対して symbolicatecrash を実行します
ここで説明されているビルド UUID を抽出するための新しいプロセスがあります。
https://developer.apple.com/library/ios/qa/qa1765/_index.html
これは、ビルド UUID を抽出するために実行する魔法のコマンドです。
xcrun dwarfdump --uuid Example.app/Example | tr '[:upper:]' '[:lower:]' | tr -d '-'
役立つかもしれない少しの追加情報。
2 つの UUID がリストされていますが、最初の 1 つはクラッシュ ログの 1 と一致し、2 番目の UUID とは一致しません。ただし、私のクラッシュはARM6を実行しているデバイスから発生していますが、OPはARM7を実行しているデバイスから発生しました
したがって、各 UUID はアーキテクチャに一致すると推測します。ARM6 および ARM7 用にビルドし、ARM6 を実行しているデバイスからクラッシュが発生した場合は、最初の UUID を一致させる必要があります。ARM7 を実行している場合は、2 番目の UUID が必要です。
UUID が 1 つしかない場合は、おそらく 1 つのアーキテクチャー用にのみビルドしたと思います。
これは主に控除ですが、可能性が高いようです。