iphone - 了解用于查找内存泄漏的 'leaks' 命令行实用程序

Question

我正在努力追踪我的 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 Static Analyzer。我已经清理了 Clang Static Analyzer 向我报告的所有内存泄漏。 Instruments 对我来说是臃肿的和无信息的。我收到了大量关于泄漏的报告，但堆栈跟踪显示的这些报告都没有返回到我自己的代码——尽管我确定泄漏确实在我的代码中。我想弄清楚如何在此处使用 cmd 行泄漏工具。

谢谢大家。

编辑:即使在取消对清理泄漏的行的注释之后，“泄漏”实用程序的提示甚至比发生泄漏时还要多。 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....

Answer 1

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

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

% MallocStackLogging=1 leaks …

您可能还想使用 -nocontent 选项，它会抑制十六进制转储。但是，不要一直使用它:有时十六进制转储包含有值(value)的线索。

此外，漏气并不一定告诉您有三处漏气；准确地说，它告诉您有三个泄漏的对象。您展示的故意泄漏只会产生一个泄漏对象，但不同的泄漏(例如在循环或频繁调用的方法中)可能会泄漏许多对象。

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