iOS libsystem_c.dylib strdup 内存泄漏 NSZombie 不工作
请帮我找出 iOS 内存泄漏问题。谢谢！
我正在使用 xCode 4.0.1，我尝试激活 NSZombie 来跟踪内存泄漏，但它似乎不像以前那样工作，使用 xCode 3.x
我无法找出内存泄漏来自哪里，正如 Instruments 指出的那样：
Leaked Object -> GeneralBlock-32 地址-> 0x4c8600 尺寸-> 32字节 负责任的图书馆-> libsystem_c.dylib 负责框架/调用者 -> strup
此时我不知道我是否在 xCode 4 中以正确的方式将 Instruments 与 NSZombie 一起使用，因为当我单击时它不会显示 NSZombie 选项“i”了解更多信息，位于左侧选项泄漏下。
观察：我的 iPhone 应用程序在有限的时间内播放实时流 mms/wma 以及 wma audio 文件。泄漏仅发生在有限的 wma 文件中，但当我从流媒体源播放时运行完美，没有结束时间。
Please help me track down an iOS memory leak. Thanks!
I'm using xCode 4.0.1 and I tried to activate NSZombie to track a memory leak, but it doesn't seems to work as before, with xCode 3.x
I can't find out where the memory leak is coming from, as Instruments points this out:
Leaked Object -> GeneralBlock-32
Address -> 0x4c8600
Size -> 32 Bytes
Responsible Library -> libsystem_c.dylib
Responsible Frame/Caller -> strup
At this point I don't know If I'm using Instruments with NSZombie the right way with xCode 4, as it doesn't show the NSZombie option when I click "i" for more information, under the left option Leaks.
OBSERVATION: My iPhone application plays a live stream mms/wma and also wma áudio files with a finite amount of time. The leak happens only with a finite wma file, but runs perfectly when I'm playing from a streamed source, with no ending time.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
首先，这是一个
malloc块，而不是一个对象。僵尸将不起作用（并且在以前的版本中也永远不会起作用）。这种泄漏发生了多少次？一次？别担心。每个流一次？提交一个错误——从您到目前为止发布的内容来看，该错误不在您的代码中（除非您的代码正在调用
strdup，这当然是可能的，但在大多数不重的 iOS 应用程序中是不常见的使用第三方库...是吗？）在任何情况下，除非它在应用程序运行时泄漏数百个和数百个 32 字节分配，否则不要担心（但请提交错误）。
正如 Valkio 所说，您可以直接从 gdb （或 Instruments）获取分配的堆栈跟踪。
First, that is a
mallocblock, not an object. Zombies won't work (and would never have worked in prior versions either).How many times does that leak happen? Once? Don't worry about it. Once per stream? file a bug -- that isn't in your code from what you have posted so far (unless your code is calling
strdup, which is certainly possible but atypical in most iOS apps that aren't making heavy use of third party libraries... are you?)In any case, unless it is leaking 100s and 100s of 32 byte allocations across the runtime of your app, don't worry about it (but please do file a bug).
As Valkio said, you can grab the stack trace of the allocation from gdb (or from Instruments) directly.
如果执行以下操作，您可以看到它的分配位置：
（调试）->论据。
You can see where it was allocated if you do this:
(Debug) -> Arguments.