如何找到因缺少 NSAutoreleasePool 而发生泄漏的线程?

发布于 2024-12-08 19:38:15 字数 262 浏览 0 评论 0原文

当我运行我的应用程序时,我收到此消息:

*** __NSAutoreleaseNoPool(): Object 0xadf5e50 of class __NSDate autoreleased with no pool in place - just leaking

我知道我需要在发生这种情况的线程开头创建一个 NSAutoreleasePool,但我不确定在我的代码中发生这种情况。是否可以设置一个断点,当有问题的对象自动释放时将被命中?

I'm getting this message when I run my app:

*** __NSAutoreleaseNoPool(): Object 0xadf5e50 of class __NSDate autoreleased with no pool in place - just leaking

I understand that I need to create an NSAutoreleasePool at the start of the thread that this is happening on, but I'm not sure where in my code this is happening. Is it possible to set a breakpoint that will be hit when the object in question is autoreleased?

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

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

发布评论

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

评论(3

拔了角的鹿 2024-12-15 19:38:15

您可以在 __NSAutoreleaseNoPool 上设置一个符号断点,然后查看当您点击它时您所在的线程。这可以使用 Xcode 断点导航器底部的 UI 来完成,或者如果您愿意,也可以在 GDB 命令行上输入以下命令来完成:break __NSAutoreleaseNoPool

You could set a symbolic breakpoint on __NSAutoreleaseNoPool and see which thread you're on when you hit it. This can be done using the UI at the bottom of Xcode's Breakpoint Navigator, or on the GDB command line if you prefer, by entering the command: break __NSAutoreleaseNoPool

客…行舟 2024-12-15 19:38:15

来自 MallocStackLogging 上的 CocoaDev:

这是一个环境变量。当这个环境变量是
设置,在 tcsh 中使用“setenv MallocStackLogging 1”(例如),然后
您可以在该 shell 中启动任何应用程序。不要“打开”应用程序,启动它
从壳中。当您执行此操作时,所有 malloc 都会被跟踪。然后说,
在另一个 shell 中,“leaks”或“leaks”会给你一个
此时应用程序中可能存在大量泄漏。

然后,您可以循环执行一系列操作,看看是否有
泄漏迭代之间的变化。泄漏有一个 id,它会保留
应用程序的生命周期、大小以及有时的猜测都是相同的
被泄漏对象的类型以及起始位的转储
泄露的数据。

弄清楚如何最好地修复泄漏,以及如何解释一些问题
你在泄漏转储中看到的东西是一个单独的东西。

From CocoaDev on MallocStackLogging:

This is an environment variable. When this environment variable is
set, with "setenv MallocStackLogging 1" in tcsh (for example), then
you can launch any app in that shell. Do not "open" the app, launch it
from the shell. When you do this all mallocs are tracked. Then saying,
in another shell, "leaks " or "leaks " will give you a
potentially voluminous list of the leaks in the app at that point.

You can then loop over some series of actions and see if the number of
leaks changes between iterations. The leak has an id, which stays the
same for the lifetime of the app, the size and sometimes a guess as to
the type of the object being leaked, and a dump of the beginning bit
of the leaked data.

Figuring how best to fix the leaks, and how to intepret some of the
things you see in the leaks dump is a separate thing.

洒一地阳光 2024-12-15 19:38:15

只需在线程的主函数中添加自动释放池就可以解决内存管理问题。
像这样

- (void)main
{
    NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
    ...
    Your code here
    ...

    [pool release];
}

或者如果你想使用新的语法

- (void)main
{
    @autoreleasepool {
        ... your code here ...
    }
}

无论如何,你应该检查所有由工厂方法创建的或由你明确自动发布的 NSDate 。下面列出了 NSDate 类的所有工厂方法

  • date

  • dateWithNaturalLanguageString:

  • dateWithString :

  • dateWithTimeIntervalSinceNow:

  • dateWithTimeInterval:sinceDate:

  • dateWithTimeIntervalSinceReferenceDate:

  • dateWithTimeIntervalSince1970:

来自Apple 文档)

Simply adding an autorelease pool in your main function of your thread should fix your memory management problem.
Like this

- (void)main
{
    NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
    ...
    Your code here
    ...

    [pool release];
}

or if you want to use the new syntax

- (void)main
{
    @autoreleasepool {
        ... your code here ...
    }
}

Anyway, you should check all the NSDate created by a factory method or expressly autoreleased by you. All the factory method for the class NSDate are listed below

  • date

  • dateWithNaturalLanguageString:

  • dateWithNaturalLanguageString:locale:

  • dateWithString:

  • dateWithTimeIntervalSinceNow:

  • dateWithTimeInterval:sinceDate:

  • dateWithTimeIntervalSinceReferenceDate:

  • dateWithTimeIntervalSince1970:

(from Apple documentation)

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