3

Xcodeがクラッシュするたびに、main.mのこの行を指します。

int retVal = UIApplicationMain(argc, argv, nil, @"AppController");

Xcode 4のデバッグは3.xと比較して悪臭を放っていますが、クラッシュが発生した行をポイントするにはどうすればよいですか。

しないでください：

  1. NSZombieEnabledを有効にするように教えてください。
  2. CatchまたはThrowのすべての例外をブレークするために、例外ブレークポイントを追加するように指示してください。
  3. デバッグにはXcode4.xの方が3.xよりも優れていると教えてください。

これらはすべて役に立たないか、ほとんど役に立たず、Xcodeはmain.mの同じ行でクラッシュし続けます...

これから私を救ってください。

ありがとう。

4

2 に答える 2

5

アイデアは次のとおりです。アプリ全体を1回試行/キャッチし、現在のスタックではなく、例外からスタックをログに記録します（つまり、ブレークポイント+検査ではありません）。

main.m

int main(int argc, char *argv[])
{
    @autoreleasepool {
        @try {
            return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]));
        }
        @catch (NSException *exception) {
            NSLog(@"%@",[exception callStackSymbols]);
            return 1;
        }
    }
}

私の理解では、他の方法で適切な方法がない理由は、クラッシュ自体が実行ループの後半まで発生しないためです。キャッチされない例外などのようなものは、runloopが繰り返されるときにAppleのコードのどこかでクラッシュする状態にアプリを置くだけだと思います。これは、UIでクラッシュが発生した場合と似ています...くだらないジオメトリを設定したときに常にクラッシュするわけではなく、使用しようとするとクラッシュします。このため、クラッシュが実際に発生したときの現在の状態からではなく、例外オブジェクトからスタックを取得する必要があります。

情報がないと思ったときに何度か得られたので、これを追加しますが、Xcodeについてはまだ十分に理解していませんでした（これは常識であり、ばかげているだけでした）。時々、私が持っているのは恐ろしいトップレベルのスコープだけだと思う​​とき、私がする必要があるのは、スタック全体を表示するために左下の小さなスライダーを使用することだけでした。上記の理由により、これはほとんど役に立たないことがよくあります（問題の実行ループの別の部分にあります）。

折りたたまれたスタック 拡張スタック

于 2012-07-13T01:56:18.653 に答える
2

明らかにあなたは調査を行い、同じ答えを思いついただけです。それには理由があります。残念ながら、Xcode 4.xで使用できるのはこれらだけなので、別の答えを出すことはできません。

私が提案できるのは、前述のすべての修正をすでに実行していて、リンクされたフレームワークまたはライブラリを使用している場合、これらがクラッシュが発生する正確な行を取得できない主な理由である可能性があるということです。リンクされたライブラリはすでにコンパイルされており、クラッシュの正確な行を表示できませんが、エラーが発生したおおよその場所とその原因となっているライブラリを特定できれば、問題の根本原因に焦点を当てることができます。問題のある行を見つけます。

于 2012-07-13T01:41:14.747 に答える