libsystem_c.dylib 中的内存泄漏答案

【问题标题】：Memory Leak in libsystem_c.dyliblibsystem_c.dylib 中的内存泄漏
【发布时间】：2012-08-02 06:53:18
【问题描述】：

我在我的应用程序中发现了内存泄漏，该应用程序是 ARC 转换的应用程序。

仪器显示泄漏责任库是libsystem_c.dylib

我在这里附上屏幕截图..

我已经搜索过这个问题，我在

obj-c-memory-leak-of-malloc-48-bytes-in-strdup-framework

这是 iOS 5.1 框架中的错误吗？

对此的任何帮助表示赞赏。

【问题讨论】：

我将此解释为由strdup 函数创建的字符串永远不会被释放。如果您不使用strdup，问题可能出在其他地方。你能发布电话的回溯吗？
是的，这是目前 5.1 和 5.1.1 中的一个已知错误。如果我没记错的话，与滚动视图有关。

标签： iphone objective-c memory-leaks instruments

【解决方案1】：

编辑：

确实，iOS SDK 5.1 strdup（或相关）中似乎存在一些错误之王。请参阅developers forum 中的此线程。

如果您可以深入研究 Elements 示例（据说可以揭示该错误）并查看您是否使用相同类型的功能，那将会很有趣。

这是泄漏时的堆栈跟踪：

 0 libsystem_c.dylib malloc
 1 libsystem_c.dylib strdup
 2 libnotify.dylib token_table_add
 3 libnotify.dylib notify_register_mach_port
 4 libnotify.dylib notify_register_dispatch
 5 CoreFoundation _CFXNotificationRegisterObserver
 6 CoreFoundation CFNotificationCenterAddObserver
 7 UIKit -[UIScrollView(Static) _startTimer:]
 8 UIKit -[UIScrollView _endPanWithEvent:]
 9 UIKit -[UIScrollView handlePan:]
10 UIKit _UIGestureRecognizerSendActions
11 UIKit -[UIGestureRecognizer _updateGestureWithEvent:]
12 UIKit ___UIGestureRecognizerUpdate_block_invoke_0541
13 UIKit _UIGestureRecognizerApplyBlocksToArray
14 UIKit _UIGestureRecognizerUpdate
15 UIKit _UIGestureRecognizerUpdateGesturesFromSendEvent
16 UIKit -[UIWindow _sendGesturesForEvent:]
17 UIKit -[UIWindow sendEvent:]
18 UIKit -[UIApplication sendEvent:]
19 UIKit _UIApplicationHandleEvent
20 GraphicsServices PurpleEventCallback
21 CoreFoundation __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__
22 CoreFoundation __CFRunLoopDoSources0
23 CoreFoundation __CFRunLoopRun
24 CoreFoundation CFRunLoopRunSpecific
25 CoreFoundation CFRunLoopRunInMode
26 GraphicsServices GSEventRunModal
27 UIKit UIApplicationMain
28 TheElements 0x300a
29 TheElements 0x2fc3

您可以通过在 Instruments View 菜单中选择“Show Extended Detail”（或类似内容）来获取泄漏时的堆栈跟踪。

旧答案：

我怀疑不是。

事实上，Instruments 向您展示的“责任库”是实际的malloc 调用被有效执行的地方。

如果您查看 Instruments 输出，罪魁祸首是 strdup：strdup 中不可能存在泄漏。

您更有可能要求操作系统（直接或间接）复制某些字符串，但随后错误地管理了生成的字符串副本。

分析 Instruments 为您提供的扩展详细信息视图，它显示了调用 malloc 时的调用堆栈。如果您的代码与malloc 调用本身之间存在直接关系，这可能会有所帮助。但是即使详细视图没有显示这种关系，也要继续寻找代码中泄漏的原因。

更一般地说，当发现泄漏时，尝试了解您的应用程序的哪个部分正在运行（考虑到泄漏分析是在离散时间进行的，例如每 10 秒一次，所以当您看到红色条出现时，这意味着泄漏是在最后 10 秒内产生的），并检查您在相关类中执行的所有内存操作。

根据我的经验，Instruments 将 SDK 的某些部分显示为对泄漏“负责”是很正常的（100% 的情况），但在更深入的分析中，错误的代码是我的一部分。

【讨论】：