了解用于查找内存泄漏的“泄漏”命令行实用程序答案

【问题标题】：Making sense of the 'leaks' command line utility for finding memory leaks了解用于查找内存泄漏的“泄漏”命令行实用程序
【发布时间】：2010-10-20 03:38:21
【问题描述】：

我正在努力追踪我的 iPhone 程序中一些难以发现的内存泄漏。我正在对一个应用程序进行快速测试，该应用程序使用以下故意 - 错误 - 代码泄漏 NSString 对象：

-(void)applicationDidFinishLaunching:(NSNotification *)notification;
{
    NSMutableString *test = [[NSMutableString alloc] init];
    [test appendString:@"Testing 1"];
    [test appendString:@"\nTesting 2"];
    NSLog(@"%@", test);

    // Uncomment the following line to release the
    // string and clean up your leak.
    // [test release], test = nil;
}

在应用程序的进程 ID 上运行泄漏后，我想出了以下内容：

sf$ leaks 3951
Process 3951: 9988 nodes malloced for 1260 KB
Process 3951: 3 leaks for 128 total leaked bytes.
Leak: 0x163b50  size=64 instance of 'NSCFDictionary', type ObjC, implemented in Foundation  
    0xa07e0720 0x01001080 0x0000000a 0x00000010      .~.............
    0x0000000a 0x0000000c 0x0000000b 0x00000000     ................
    0x00000000 0x00000015 0xa1b1c1d3 0x00163b90     .............;..
    0x00163bd0 0x00000000 0x00000000 0x00000000     .;..............
Leak: 0x178190  size=32 string 'Testing 1
Testing 2'
Leak: 0x178210  size=32 instance of 'NSCFString', type ObjC, implemented in CoreFoundation  
    0xa02e24a0 0x010007ad 0x00178190 0x00000013     .$..............
    0x00000020 0x00000200 0x00000000 0x00000000      ...............

现在，我们都知道漏洞在哪里了。这不是这个练习的重点，至少对我来说。我试图了解如何理解这个输出。有人告诉我有 3 处泄漏。

它们是位于内存地址 0x163b50、0x178190、0x178210 的对象。根据“泄漏”，他们的实现是在 Apple 框架中，而不是我的代码中。在下面这样一个简单的例子中，找到泄漏点并不难。但是，在一个有 500K 行代码的应用程序中，我发现泄漏的输出在这里毫无用处。

我做错了什么？如何理解此输出以帮助我找到我为清理内存泄漏而编写的代码中的罪魁祸首？

请注意，此线程不应提倡使用 Instruments 或 Clang 静态分析器。我已经清理了 Clang 静态分析器向我报告的所有内存泄漏。 Instruments 对我来说是臃肿且无信息的。我收到了大量关于泄漏的报告，但堆栈跟踪显示的任何一个都没有回到我自己的代码中——尽管我确信泄漏确实在我的代码中。我想在这里弄清楚如何使用命令行泄漏工具。

谢谢大家。

编辑：即使取消注释以清理泄漏，“泄漏”实用程序的抱怨甚至比泄漏时还要多。 Foundation/Cocoa 是否从这样一个微不足道的例子中泄漏了那么多？取消注释上述测试字符串的版本后会发生这种情况：

sf$ leaks 4383
Process 4383: 9890 nodes malloced for 1255 KB
Process 4383: 7 leaks for 560 total leaked bytes.
Leak: 0x163920  size=176    instance of 'NSPathStore2', type ObjC, implemented in Foundation    
    0xa07e2ae0 0x04f00000 0x0055002f 0x00650073     .*~...../.U.s.e.
    0x00730072 0x0073002f 0x002f0066 0x0069004c     r.s./.s.f./.L.i.
    0x00720062 0x00720061 0x002f0079 0x00700041     b.r.a.r.y./.A.p.
    0x006c0070 0x00630069 0x00740061 0x006f0069     p.l.i.c.a.t.i.o.
    0x0020006e 0x00750053 0x00700070 0x0072006f     n. .S.u.p.p.o.r.
    0x002f0074 0x00490053 0x0042004d 0x002f004c     t./.S.I.M.B.L./.
    0x006c0050 0x00670075 0x006e0069 0x002f0073     P.l.u.g.i.n.s./.
    0x00650054 0x006d0072 0x006e0069 0x006c0061     T.e.r.m.i.n.a.l.
    ...
Leak: 0x163350  size=160    instance of 'NSPathStore2', type ObjC, implemented in Foundation    
    0xa07e2ae0 0x04a00000 0x0055002f 0x00650073     .*~...../.U.s.e.
    0x00730072 0x0073002f 0x002f0066 0x0069004c     r.s./.s.f./.L.i.
    0x00720062 0x00720061 0x002f0079 0x00700041     b.r.a.r.y./.A.p.
    0x006c0070 0x00630069 0x00740061 0x006f0069     p.l.i.c.a.t.i.o.
    0x0020006e 0x00750053 0x00700070 0x0072006f     n. .S.u.p.p.o.r.
    0x002f0074 0x00490053 0x0042004d 0x002f004c     t./.S.I.M.B.L./.
    0x006c0050 0x00670075 0x006e0069 0x002f0073     P.l.u.g.i.n.s./.
    0x00650044 0x0069006c 0x00690063 0x0075006f     D.e.l.i.c.i.o.u.
    ...
Leak: 0x1635a0  size=64 instance of 'NSCFDictionary', type ObjC, implemented in Foundation  
    0xa07e0720 0x01001080 0x0000000a 0x00000010      .~.............
    0x0000000a 0x0000000c 0x0000000b 0x00000000     ................
    0x00000000 0x00000015 0xa1b1c1d3 0x001635e0     .............5..
    0x00163620 0x00000000 0x00000000 0x00000000      6..............
Leak: 0x163620  size=64 
    0xa02ed360 0x00160ee0 0x00163700 0xa02efc00     `........7......
    0x00000000 0x00000000 0x00163680 0x00000000     .........6......
    0x00000000 0x00000000 0x00163660 0xa02ed440     ........`6..@...
    0xa02ec1a0 0xa02f0420 0x00000000 0x00163660     .... ./.....`6..
Leak: 0x163680  size=48 instance of 'NSCFString', type ObjC, implemented in CoreFoundation  
    0xa02e24a0 0x0100078c 0x6d6f6323 0x6c65642e     .$......#com.del
    0x6f696369 0x61737375 0x69726166 0x6c65442e     icioussafari.Del
    0x6f696369 0x61537375 0x69726166 0x00000000     iciousSafari....
Leak: 0x163660  size=32 instance of 'NSCFString', type ObjC, implemented in CoreFoundation  
    0xa02e24a0 0x0200078c 0x6c65440f 0x6f696369     .$.......Delicio
    0x61537375 0x69726166 0x00000000 0x00000000     usSafari........
Leak: 0x160ee0  size=16 instance of 'NSCFString', type ObjC, implemented in CoreFoundation  
    0xa02e24a0 0x0100078c 0x362e3103 0x00000000     .$.......1.6....

【问题讨论】：

这是 Mac 应用还是 iphone 应用？你能在 iphone 上使用 mac 上的泄漏二进制文件吗？

标签： iphone objective-c cocoa cocoa-touch memory-leaks

【解决方案1】：

您显示的输出中没有堆栈跟踪。您看到的地址是对象自己的地址，而不是函数指针，标点符号旁边的十六进制数字只是数据的十六进制转储。

要找出对象是从哪里分配的，请在泄漏的环境中设置 MallocStackLogging：

% MallocStackLogging=1 leaks …

您可能还想使用 -nocontent 选项，该选项将禁止十六进制转储。但是，不要一直使用它：有时十六进制转储包含有价值的线索。

另外，leaks 并不一定告诉你有 3 个漏洞；准确地说，它告诉您有三个泄露的对象。您展示的故意泄漏只会产生一个泄漏对象，但不同的泄漏（例如在循环或经常调用的方法中）可能会泄漏许多对象。

编辑：顺便说一句，其中一些泄漏来自 SIMBL 或您的一个或多个 SIMBL 插件。在寻找泄漏之前关闭 SIMBL 和任何其他输入管理器黑客。请记住，该代码在您的进程中运行；此外，leaks 并不关心谁的代码分配或泄漏了内存，只关心它被泄漏了，因此无论是谁分配或泄漏它，它都会显示泄漏的对象。

【讨论】：

谢谢彼得。我不知道 SIMBL 是什么，但我会查一下。

【解决方案2】：

我认为您在泄漏中看到这一点的原因是 appendString 在内部使用 autorelease。直到下一个“事件”，自动释放池才会被丢弃。基本上，我认为示例过于简单，无法准确显示发生了什么。

我在这里可能有点离谱，但我会尝试将您的代码包装在自动释放池中以查看发生了什么变化。

-(void)applicationDidFinishLaunching:(NSNotification *)notification;
{
    NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
    NSMutableString *test = [[NSMutableString alloc] init];
    [test appendString:@"Testing 1"];
    [test appendString:@"\nTesting 2"];
    NSLog(@"%@", test);
    [test release], test = nil;
    [pool release] // this should drain the autorelease pool
}

【讨论】：

【解决方案3】：

对于此示例，泄漏报告 3 次泄漏，总共 128 个字节。解释如下：

1) 您正在泄漏一个 NSMutableString，它似乎在内部实现为 NSCFDictionary，总共 64 个字节

2) 您正在泄漏测试 1，总共 32 个字节

3) 你正在泄漏\n测试 2 总共 32 个字节

这应该是因为如果您不释放 NSMutableString，则不会释放任何属于 NSCFDictionary 数据结构的对象（在本例中为字符串）：每次使用 appendString 方法时都会保留它们。当你释放 NSMutableString 时，NSCFDictionary 中的所有对象都会自动释放，连同 NSCFDictionary 本身。

来自 Apple 文档 (http://developer.apple.com/iPhone/library/documentation/Performance/Conceptual/ManagingMemory/Articles/FindingLeaks.html)：

如果 Cocoa 对象在没有自动释放池的情况下自动释放，Xcode 会向控制台发送一条消息，警告您该对象正在泄漏。即使您不是在编写 Cocoa 应用程序，也可能会看到相同类型的控制台警告。许多 Cocoa 类的实现基于 Core Foundation 类型。如果您的应用程序使用 Core Foundation，则可能由于调用该框架而发生泄漏。

要查找这种类型的内存泄漏，请使用调试器在 _NSAutoreleaseNoPool 函数上放置断点。该函数在 Foundation 框架的 NSDebug.h 中声明。当调试器到达该函数时，您应该能够查看堆栈爬网并查看是哪段代码导致了泄漏。

【讨论】：