2

そのため、テスターから取得したクラッシュ ログのトラブルシューティングに少し苦労しています。アプリは でクラッシュし、EXC_CRASH (SIGSEGV)いずれかのスレッドで唯一認識可能なコードはスレッド 6 にあります。スタック トレースは次のようになります。

...
15  MyApplication                   0x002cfcf2 0xfb000 + 1920242
16  MyApplication                   0x00107f26 -[CCViewController dealloc] (CCViewController.m:73)
17  MyApplication                   0x001cc27c -[CCSubmitReportController dealloc] (CCSubmitReportController.m:646)
18  CoreFoundation                  0x36f41c3c 0x36f3f000 + 11324
...
26  Foundation                      0x35396bd4 0x35387000 + 64468
27  MyApplication                   0x001c794e -[CCGetFeedOperation main] (CCGetFeedOperation.m:102)
...

の102 行目を見るとCCGetFeedOperation、作業の最後に操作の自動解放プールが空になっているだけです。

だから私は、自動解放プールがデリゲートを解放しようとする理由を理解しようとしています。デリゲートへの参照は、次のように操作クラスに渡されます。

@property (assign) id <CCGetFeedOperationDelegate> feedDelegate;

私が考えることができる唯一のことは、メイン スレッドでメソッドを呼び出し、それが完了するのを待ってからプール ドレインを呼び出すということです。

invocation = [NSInvocation invocationWithTarget:feedDelegate
                                                       selector:@selector(operation:didGetFeed:) 
                                            retainArguments:YES, self, feedDetailsModel];

しかし、それでも、操作のプールによってビュー コントローラーの割り当てが解除される理由を説明できるとは限りません。考え？

編集：ところで、これを再現できませんでした。私は、テスターと野生の人々からのクラッシュレポートでしか見たことがありません.

編集 2: 自動解放プールは非常に単純で、操作のmainメソッドの開始時に割り当てられ、作業が完了すると排出されます。

4

1 に答える 1

4

自動解放プールのドレイン中にクラッシュした場合は、そのイベント ループ中にどこかで何かを過剰に解放したことを意味します。同じオブジェクトに自動解放がある場合、プールが空になるまでクラッシュは発生しません。自動解放がそれと関係があるという意味ではありません。それはちょうど最後のリリースが起こったときです。

すべてのプロパティ アクセスにアクセサーを使用していることを確認してください (init と dealloc を除く)。ivar への直接アクセスは、非 ARC コードでこの種のクラッシュが発生した場合の最大の原因です。いずれにせよ、保持と解放のバランスを監査する必要があります。ARC に移行すると、通常、これらの種類のエラーが減少するため、可能な場合は強くお勧めします。

于 2013-04-02T00:16:05.327 に答える