NSZombiesは私のアプリの脳を食べています！

Question

私は保持/解放の問題があります。私のビューはかなり複雑ですので、NSZombieEnabledをYESに設定しています。オブジェクトが私に悲しみを引き起こしている場所を特定しようとしています。このプロセスをスピードアップするために、ゾンビを墓地に戻して追跡するヒントやトリックがあれば、彼らが連れてきたオブジェクトを掘り起こしたり、戻ったり、戻ったりするのだろうか？奇妙なコンソールメッセージは、多くの洞察を提供するようには見えない：

私は「トラブルの先を行く」というセレクターを持っていない。

編集 - スタックトレースを含む：

#0 0x3026e017 in ___forwarding___ 
#1 0x3024a0a2 in __forwarding_prep_0___ 
#2 0x302042e8 in CFRelease 
#3 0x00c4fc31 in CALayerUpdateSublayers 
#4 0x00c4e173 in -[CALayer dealloc] 
#5 0x00c4000e in CALayerRelease 
#6 0x00c48dad in CALayerFreeTransaction 
#7 0x00c410b8 in CA::Transaction::commit 
#8 0x00c492e0 in CA::Transaction::observer_callback 
#9 0x30245c32 in __CFRunLoopDoObservers 
#10 0x3024503f in CFRunLoopRunSpecific 
#11 0x30244628 in CFRunLoopRunInMode 
#12 0x32044c31 in GSEventRunModal 
#13 0x32044cf6 in GSEventRun 
#14 0x309021ee in UIApplicationMain 
#15 0x00001eb4 in main at main.m:14 

編集2：掘り下げる

# Address  Category   Creation Time  Size Responsible Library Responsible Caller 
0 0x1076980 GeneralBlock-48 00:11.470  48  QuartzCore -[CALayer setDelegate:] 
1 0x1076980 CALayer   00:11.552  48  UIKit  -[UIView _createLayerWithFrame:] 

：ObjectAlloc

ObjectAllocで問題になっているメモリアドレスを見上げる私は2試合を見つけます＃0 GeneralBlock-48：

＃1のCALayerを掘り下げる

：

# Category  Event Type Timestamp Address Size Responsible Library Responsible Caller 
0 GeneralBlock-48 Malloc  00:11.470 0x1076980 48 QuartzCore -[CALayer setDelegate:] 
1 GeneralBlock-48 Free  00:11.551 0x1076980 -48 QuartzCore -[CALayer addAnimation:forKey:] 
2 CALayer   Malloc  00:11.552 0x1076980 48 UIKit -[UIView _createLayerWithFrame:] 

まあ、私は＃0または＃1のいずれかに深く掘削すると、まったく同じ情報を明らかにすることを今参照してください。あなたが行うことができます

Answer 1

私は、バックトレースはちょうどゾンビがメッセージされているポイントだと思います。このバックトレースは、通常、クラッシュを引き起こしていることに関する情報をゼロにします。それは、あなたに、リリースされているオブジェクトのタイプとアドレスだけを示しています。

このようなオーバーリリースを追跡するためによく使用する手法は、InstrumentsのObjectAllocを使用してすべての保持と解放を追跡することです。 ObjectAllocでオーバーリリースされたオブジェクトのアドレスを見つけて、すべての保持/解放呼び出しをリストし、各保持とリリースのバランスをとります。一度あなたが一致する保持なしのリリースを見つけると、あなたは問題を発見しました。

Answer 2

一つの迅速な事がobjc_exception_throwでシンボリックブレークポイントを設定されている...私は半分にこのトラブルシューティングをカットしなければならないと仮定...しかし、私は途方に暮れてまだです。これにより、例外がスローされるたびにプログラムが一時停止します。これはを正確にに追跡するのに役立ちません。CALayerはあなたに悲しみを与えていますが、それが呼び出されている場所の一般的な周辺を見つけるのに役立ちます。

Answer 3

"トラブルが先に"は警告の一部であり、セレクターではありません。警告自体はNSInvocationから来ていますが、 "class _NSZombie_CALayer"という記述は、何かが解放されたCALayerで動作しようとしていることを意味しています。

スタックトレースは、レイヤがそのサブレイヤを解放しようとしているときに発生していることを示します。

これは、リリースされているレイヤーに、コードのどこかでオーバーリリースされたサブレイヤがあることを意味します。 CALayersのメモリ管理を確認するか、Clang Static Analyzerを試してみてください。