0

この問題はライフサイクルの問題だと思います。アプリはメモリ警告を受け取り、いくつかのユーザー インターフェイス項目をアンロードしようとします。しかし、スタック トレースで最後に報告された項目のコンテキストでエラーを解釈する方法を 100% 確信しているわけではありません。

Exception Type:  SIGSEGV
Exception Codes: SEGV_ACCERR at 0xa0d9f968
Crashed Thread:  0

Thread 0 Crashed:
0   libobjc.A.dylib                     0x361dc026 objc_msgSend_stret + 18
1   TheApp                              0x000b4d31 -**[TheAppFeedController removeAdView]** (TheAppFeedController.m:**189**)
2   TheApp                              0x0000d68d -[TheAppViewController viewDidUnload] (TheAppViewController.m:177)
3   TheApp                              0x000b4a63 -[TheAppFeedController viewDidUnload] (TheAppFeedController.m:137)
4   UIKit                               0x32e66a37 -[UIViewController unloadViewForced:] + 251
5   UIKit                               0x32fae3ad -[UIViewController purgeMemoryForReason:] + 65

そのため、スタック トレースはこのメソッドを指していますが、なぜこのエラーがスローされるのか、実際には意味がありません。

-(void) removeAdView {
    [super removeAdView];
    [self fixLayoutForAdRemoval:self.tableView];
}

スタックを調べたときに気づいたことの 1 つは[super viewDidUnload]、コードの最初の行として呼び出されていたことです。それで、すべての「荷降ろし」作業を行った後、それを一番下に移動しました。これが本当に重要かどうかにかかわらず、オンラインで意見の相違があるようです.スーパークラスのメソッドは何もしないというSOの回答viewDidUnloadもあります.そのため、最初または最後に呼び出すかどうかは問題ではありません.

そのため、その変更を行いましたが、このエラーを再現できなかったため、実際の修正かどうかはわかりません。私の推論が正しいかどうかを確認するために、問題についてより多くの意見を得たいと思っていました。

4

1 に答える 1

1 
[super removeAdView];
[self fixLayoutForAdRemoval:self.tableView];

removeAdView自己の一部を破壊している場合。self割り当て解除のポイントまで解放される原因となっている場合、後続の への呼び出しfixLayoutForAdRemoval:は簡単に失敗する可能性があります。

Instruments でゾンビ検出をオンにして、検出されたものを確認します。

于 2012-10-24T16:46:04.153 に答える