iOS libsystem_c.dylib strdup 内存泄漏 NSZombie 不工作答案

【问题标题】：iOS libsystem_c.dylib strdup memory leak NSZombie not workingiOS libsystem_c.dylib strdup 内存泄漏 NSZombie 不工作
【发布时间】：2011-08-19 10:57:25
【问题描述】：

请帮助我找出 iOS 内存泄漏。谢谢！

我正在使用 xCode 4.0.1 并尝试激活 NSZombie 以跟踪内存泄漏，但它似乎不像以前那样使用 xCode 3.x

正如 Instruments 指出的那样，我无法找出内存泄漏的来源：

泄漏对象 -> GeneralBlock-32 地址 -> 0x4c8600 大小 -> 32 字节 负责库 -> libsystem_c.dylib 负责任的框架/调用者 -> strup

此时我不知道我是否以正确的方式将 Instruments 与 NSZombie 与 xCode 4 一起使用，因为当我单击“i”以获取更多信息时，它不会显示 NSZombie 选项信息，在左侧选项 Leaks 下。

观察：我的 iPhone 应用程序在有限的时间内播放实时流 mms/wma 和 wma áaudio 文件。泄漏仅发生在有限的 wma 文件中，但当我从流式源播放时完美运行，没有结束时间。

【问题讨论】：

标签： objective-c ios memory-leaks instruments nszombie

【解决方案1】：

首先，这是一个malloc 块，而不是一个对象。僵尸不会工作（在以前的版本中也永远不会工作）。

这种泄漏发生了多少次？一次？别担心。每个流一次？提交一个错误——这不在你目前发布的代码中（除非你的代码调用strdup，这在大多数没有大量使用第三方库的 iOS 应用程序中当然是可能的，但不是典型的……你是吗？）

在任何情况下，除非它在您的应用运行时泄漏 100 和 100 次 32 字节分配，否则不要担心（但请提交错误）。

正如 Valkio 所说，您可以直接从 gdb（或 Instruments）获取分配的堆栈跟踪。

【讨论】：

感谢您的考虑，bbum。我会提交错误报告。是的，我正在大量使用第三方库：LibMMS（用于解析音频流）和 FFMPeg（用于解码/播放）WMA 文件。在这种情况下，我应该寻找什么？因为当我打开第二个流时，在第一个流结束时，当我手动停止音频时，我的应用程序崩溃了。我自己不会调用 strdup，除非我正在使用的库正在这样做。更新：是的，LibMMS 在建立 mms 连接时正在调用 strup。
如果错误报告在第三方库中，它可能对您没有多大帮助。听起来像那个图书馆的泄漏。崩溃可能是正交的（尽管它可能归结为库中的内存管理问题）并且值得提出不同的问题。

【解决方案2】：

如果你这样做，你可以看到它被分配到哪里：

转到产品 -> 编辑方案 -> 运行（调试）-> 参数。
将此添加到环境变量中：MallocStackLoggingNoCompact
将其设置为 YES
运行，让它崩溃。
输入控制台 (gdb) info malloc 0x4c8600 或任何地址。

【讨论】：

您也可以在 Instruments 中执行此操作。不需要gdb；在 Instruments 中点击分配的地址，它会显示分配堆栈跟踪。
感谢您的回答，瓦基奥。我按照你的指示做了，在 (gdb) 中，当我输入 info malloc 0x464890 时，它给了我这个输出：MyAppName (330) > 这个 330 是什么意思？
嗯，这不对。你应该得到一个 malloc 堆栈。也许在这种情况下仪器会更好地工作......
如果你愿意，请看看我对 bbum 的回复。谢谢。
有人用很少的 malloc 泄漏解决了这个问题吗？我现在拥有它，当这些错误堆积起来时，它们会使我的应用程序崩溃......