問題タブ [dsym]

iPad を使用せずに Instruments で MonoTouch アプリケーションをプロファイリングしたいと考えています。Simulator 用にコンパイルされたアプリのプロファイルを作成できますが、シンボルがないと面白くありません。

プロジェクトのビルド設定で dSYM を使用して IPA を生成するオプションはありません。デバイス用にコンパイルする場合にのみ使用できるようです。

私が欲しいのは、シミュレーター用の MonoTouch 対応の dSYM だけです。
これは可能ですか？

ほとんどのプロジェクトで、プロジェクトをアーカイブするための「アーカイブ」スキームをセットアップし、TestFlight にアップロードできる IPA と DSYM を作成します。

ただし、プロジェクト ワークスペース内に複数のターゲット、かなりの数の静的リンク ライブラリがある、より複雑なプロジェクトに取り組んでいます。各ターゲットを確認し、すべての構成に対して次のように設定しました。

• 展開の後処理 -> いいえ
• リンクされた製品を削除... -> いいえ
• ストリップ デバッグ... -> いいえ
• デバッグ シンボルの生成 -> はい
• デバッグ情報... -> DSYM を使用した DWARF

Xcode 4.5.2 を使用しています。私は問題なく多数のプロジェクトに対してこれを行いました。これは、何かが DSYM ファイルの作成を妨げていると思われる最初のケースです。

何を試しても、アーカイブ ビルドで .DSYM ファイルが生成されません

一部のコード分析ツールでは、.ipa と .dSYM ファイルを提出する必要があります。

.ipa と一緒に .dSYM ファイルを送信すると、アプリのリバース エンジニアリングのリスクがありますか? つまり、誰かが .ipa と .dSYM の両方を持っている場合、ソース コードにアクセスできますか?

私はいくつかのバグレポートを持っています

しかし、ソース コードからこのバグを見つけることができません。このコマンドを使用してクラッシュする場所を確認しますが、コードの無関係な部分が表示されます。

atos -arch armv7 -o nuPhoto.app/nuPhoto 0x000885f9

では、.app と .app.sSYM がアプリ ストアに送信されたバージョンと同じであることを確認するにはどうすればよいでしょうか? atos を使用する代わりに、NSLog ですべての情報 (行番号とソース コードを含む) を表示することは可能ですか? ありがとうございました。

Mac OS X v10.8.3経由で Ruby 2 の開発バージョンをインストールし、rbenvそれを使用して作業中の gem をコンパイルしています。デバッグしたいメモリの問題があります。残念ながら、valgrind、gdb、またはcgdbを のコンテキストで実行するとrake spec、次のようなエラーが大量に発生します。

明らかに、そのruby-buildディレクトリはもう存在しません。

から関連する可能性のある一連のエラーが発生しvalgrindます。以下に例を示します。

その--dsymutil=yesオプションを使用しようとすると、基本的に次のものと同じエラーが発生しますgdb。

別の質問への回答として、info target内で実行してみgdbました。これが出力です。

rbenvデバッグ シンボルをクリーンアップされない場所に配置するように指示できる方法はありますか?

自作でインストールしたGCC 4.7.1を使用しています。私の正確な Ruby バージョン文字列はruby 2.1.0dev (2013-04-01 trunk 40029) [x86_64-darwin12.3.0]で、私のrbenvバージョンは 0.4.0 です。

2 つのプロジェクト ファイルを含むワークスペースがあります。1 つはアプリ コード (APP) を含み、もう 1 つは APP プロジェクトにリンクされた静的ライブラリ (Pod) をビルドします。

選択時に生成される dSYM にProduct->Archiveは、APP プロジェクトのデバッグ情報のみが含まれます。Xcodeを選択してビルドするProduct->Build For->Archiving/と、必要なすべてのデバッグ情報を含む dSYM が生成されます。

次の回答によると、これは Xcode のバグであり、現在バージョン >=4.6 で修正されています。

https://stackoverflow.com/a/15368776/215748

Xcode バージョン 4.6.2 (4H1003) を使用していますが、まだこの問題があります。

これは本当に Xcode のバグですか、それともこれを引き起こしているビルド設定がありますか?

COPY_PHASE_STRIP、STRIP_INSTALLED_PRODUCT、GCC_SYMBOLS_PRIVATE_EXTERN、および GCC_INLINES_ARE_PRIVATE_EXTERN を調べましたが、効果はありません。

dSYM ファイル内に含まれる mach-o ファイル用の単純なパーサーを作成しようとしています。16 進数エディター (TextWrangler の Hex Fiend または Hex ダンプ) でファイルを開くと、このようなものが見えます。

最初の値CEFAEDFEはFEEDFACE逆方向のMH_MAGIC数値です。実はMH_CIGMA後ろ向きだからです。これにより、残りの情報はリトルエンディアンであることがわかります。つまり、最下位バイトが最初です。の場合、0xFEEDFACE最下位バイトは です0xCE。これは上記のサンプルで最初にあり、次に残りのバイトです。

そのため、残りの整数 (4 バイト) の検査を続けます。適切にフォーマットされるように (つまり、0C000000 が 0000000C になるように) 再配置すると、次のようになります。

0000000C は、CPU_TYPE_ARM である CPU タイプです。

0000000B は、CPU_SUBTYPE_ARM_V7S である CPU サブタイプです。

0000000A は MH_DSYM であるファイルタイプです

00000007 はロード コマンドの数です。

00000D3C は、ロード コマンドが占有するバイト数です。

00000000 はフラグです (フラグなし)

0000001B は、この LC に UUID が含まれていることを示すロード コマンド LC_UUID です。

00000018 0x18 であるロード コマンドのサイズ = 24 バイト (コマンド [4 バイト] + サイズ [4 バイト] + UUID [16 バイト])

ここが奇妙になり、私の質問が来るところです。

情報はリトル エンディアンであるため、UUID (次の 16 バイト) を次のように「後方」に再配置する必要があると考えました: 9B3EAC06-3C1288AB-933B60E8-20F34EA0。ただし、dwarfdumpUUID ( dwarfdump --uuid TestApp.app.dSYM/) を取得するために使用すると、次のようになります。

なぜこれはビッグエンディアン順なのですか? dwarfdumpHex Fiend のバイトと同じ順序で表示されるのはなぜですか?

私は何が欠けていますか？

あなたの助けや提案を前もって感謝します.

C でコーディングを始めたばかりで、デフォルトの C コンパイラを gcc に設定して他の人の Makefile を実行しました。私は Mac OSX 10.8 Mountain Lion を使用していますが、「XCode コマンド ライン ツール」を使用してコンパイラをインストールしたと思います。コマンドラインで「make」を実行した後、各プログラムのこれらの厄介な .dSYM ファイルを取得します。これらはデバッグ ファイルであると読みましたが、本当に必要なのでしょうか? それらがコマンドラインから生成されないようにする方法はありますか?

iOS アプリの dSYM ファイルからアドレス、ファイル名、および行番号を解析しました。私は基本的に、アドレスをファイル名と行番号にマップするテーブルを持っています。これはデバッグに非常に役立ちます。

を取得するactual lookup addressには、クラッシュ レポートのスタック トレース アドレスを使用し、https ://stackoverflow.com/a/13576028/2758234 の回答で指定されている式を使用します。だから、このようなもの。

私はそのアドレスを使用して、自分のテーブルで調べます。取得したファイル名は正しいですが、行番号は常に、スタック トレースで次の関数を呼び出した実際の行ではなく、呼び出された関数またはメソッドの最後を指しています。

どこかで読んだのですが、フレーム アドレスはシステム ポインター サイズの 2 倍に調整されているため、タグを解除する必要があることを覚えていません。したがって、32 ビット システムの場合、ポインターのサイズは 4 バイトであるため、次のような式を使用して 8 バイトを使用してタグを解除します。

はuintptr_t、Objective-C でポインターに使用されるデータ型です。

これを行った後、ルックアップは機能しますが、タグが解除されたアドレス以下である最も近いアドレスを見つけるなどのことをしなければなりません。

質問 #1 :
スタック フレーム アドレスのタグを解除する必要があるのはなぜですか? スタック トレースで、アドレスがまだ正しい場所を指していないのはなぜですか?

質問 #2 :
クラッシュ レポートに、フレームが欠落しているように見えることがあります。たとえば、which がwhich を呼び出すとfunction1()、スタック トレースに次のように表示されます。function2()function3()function4()

また、(フレーム 2、上記) のスタック トレース アドレスfunction3()は、タグを外した後でも、正しい行番号を指していません (ただし、正しいファイルです)。これは、Xcode にクラッシュ レポートをシンボリックさせた場合でも見られます。

なぜこれが起こるのですか？