NSZombies 正在吃我应用程序的大脑!

发布于 2024-07-30 00:02:32 字数 2397 浏览 7 评论 0原文

我遇到了保留/释放问题。 我的视图非常复杂,因此我将 NSZombieEnabled 设置为 YES,并试图准确地找到哪个对象引起了我的悲伤。 为了加快这个过程,我想知道是否有提示或技巧可以追踪僵尸回到他们挖出的坟墓(抱歉,不得不),或者回到与他们相关的物体? 神秘的控制台消息似乎没有提供太多见解:

NSInvocation: warning: object 0x1076850 of class '_NSZombie_CALayer' does not implement methodSignatureForSelector: -- trouble ahead

我没有称为“前方麻烦”的选择器。

编辑 - 包括堆栈跟踪:

#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:ObjectAlloc

在 ObjectAlloc 中查找有问题的内存地址,我发现两个匹配项:

#    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:]

深入#0 GeneralBlock-48:

#   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:]

深入#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 中进行更深入的钻探会揭示完全相同的信息。 我想这应该可以将故障排除减半......但我仍然不知所措......

I've got a retain/release problem. My View is pretty complicated so I've set NSZombieEnabled to YES and am trying to locate which, exactly, object is causing me grief. To speed this process along I'm wondering if there hints or tricks to tracking the Zombies back to the grave they dug their way out of (sorry, had to) or, back to the object they're associated with? The cryptic console message doesn't appear to offer much insight:

NSInvocation: warning: object 0x1076850 of class '_NSZombie_CALayer' does not implement methodSignatureForSelector: -- trouble ahead

I have no selectors called "trouble ahead".

Edit - Including Stack Trace:

#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

Edit 2: ObjectAlloc

Looking up the memory address in question in ObjectAlloc I find two matches:

#    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:]

Digging into #0 GeneralBlock-48:

#   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:]

Digging into #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:]

Well, I see now that drilling deeper in either #0 or #1 reveals the exact same information. I suppose that should cut troubleshooting this in half...but I'm still at a loss...

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

邮友 2024-08-06 00:02:33

您可以快速做的一件事是在 objc_exception_throw 上设置符号断点。 这将导致您的程序在抛出异常时暂停。 这可能无法帮助您准确找到哪个 CALayer 正在给您带来麻烦,但它应该可以帮助您找到它被调用的大致范围。

One quick thing you can do is set a symbolic breakpoint on objc_exception_throw. This will cause your program to pause whenever an exception is thrown. This may not help you track down exactly which CALayer is giving you grief, but it should help you find the general vicinity where it's being called.

帝王念 2024-08-06 00:02:33

“前方麻烦”是警告的一部分,而不是选择器。 警告本身来自 NSInspiration,但事实上它提到“class _NSZombie_CALayer”意味着某些东西正在尝试使用已被释放的 CALayer。

堆栈跟踪表明,当某个层尝试释放其子层时,就会发生这种情况。

总而言之,这意味着正在释放的层有一个子层已在代码中的某处过度释放。 检查您的 CALayers 内存管理,或尝试 Clang 静态分析器

“trouble ahead” is part of the warning, not the selector. The warning itself comes from NSInvocation, but the fact that it mentions “class _NSZombie_CALayer” means that something’s trying to work with a CALayer that’s been dealloced.

The stack trace indicates that this is happening when a layer is trying to release its sublayers.

Altogether, this means that the layer being released has a sublayer that has been over-released somewhere in your code. Check your memory management of CALayers, or try the Clang Static Analyzer.

北座城市 2024-08-06 00:02:33

我相信回溯只是向僵尸发送消息的点。 此回溯通常为您提供有关导致崩溃的原因的零信息。 它几乎只告诉您正在过度释放的对象的类型和地址。

我经常用来跟踪像这样的过度释放的技术是使用 Instruments 的 ObjectAlloc 来跟踪所有保留和释放。 在ObjectAlloc中找到过度释放对象的地址,然后列出所有retain/release调用,然后尝试平衡每个retain与release。 一旦找到没有保留匹配的版本,您就发现了问题。

I believe the backtrace is just the point where the zombie is being messaged. This backtrace usually gives you zero information about what is causing the crash. It pretty much only tells you the type and the address of the object that is being over-released.

A technique I often use to track down over-releases like this is to use Instruments' ObjectAlloc to track all retains and releases. Find the address for the over-released object in ObjectAlloc, then list all the retain/release calls, and then try to balance each retain with a release. Once you find a release without a retain to match, You've found the problem.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文