内存泄漏追踪的改进

Question

我花了整整一个星期的时间来追踪和解决内存泄漏问题，而在那周的另一端我却有点茫然。 必须有更好的方法来做到这一点，就是我所能想到的，所以我认为是时候问这个相当沉重的话题了。

这篇文章相当庞大。对此表示歉意，但我认为在这种情况下，尽可能彻底地解释细节是有必要的。之所以如此，是因为它让你全面了解我为找到这个混蛋所做的所有事情，这涉及到很多事情。仅这个错误就花了我大约三天 10 多个小时的时间来追踪...

当我寻找泄漏时

当我寻找泄漏时，我倾向于分阶段进行，如果满足以下条件，我会“更深入”地升级问题：它在早期阶段是无法解决的。这些阶段从 Leaks 告诉我存在问题开始。

在这种特殊情况下（这是一个例子；错误已解决；我不是在寻求解决此错误的答案，而是在寻求改进我发现错误的过程的方法） ），我在一个相当大的多线程应用程序中发现了一个泄漏（甚至两个），特别是包括我在其中使用的 3 个左右的外部库（解压缩功能和 http 服务器）。那么让我们看看我修复这个泄漏的过程。

第 1 阶段：Leaks 告诉我有泄漏

_{（来源：enrogue.com）}

嗯，这很有趣。由于我的应用程序是多线程的，我的第一个想法是我忘记在某个地方放置一个 NSAutoreleasePool ，但在检查了所有正确的位置后，情况并非如此。我查看了堆栈跟踪。

阶段 2：堆栈跟踪

_{（来源：enrogue.com）}

两个 GeneralBlock-160 泄漏具有相同的堆栈跟踪（这很奇怪，因为我将其按“相同的回溯”分组，但无论如何），从 thread_assign_default 开始，到 malloc< _NSAPDataCreate 下的 /code>。在这两者之间，绝对没有任何东西与我的应用程序相关。这些电话中没有一个是“我的”。所以我做了一些谷歌搜索来弄清楚这些可能有什么用处。

首先，我们有许多显然与线程回调有关的方法，例如 POSIX 线程调用进入 NSThread 调用。

在这个（反向）堆栈跟踪中的 #8-6 处，我们有 +[NSThread exit] ，后面是 pthread_exit 和 _pthread_exit ，这很有趣，但根据我的经验，我无法真正判断它是否表明了某些特定情况，或者是否只是“事情如何发展”。

之后，我们有一个名为 _pthread_tsd_cleanup 的线程清理方法 - 无论“tsd”代表什么，我不确定，但无论如何，我都会继续。

在#4-#3，我们有：

CA::Transaction::release_thread(void*)
CAPushAutoreleasePool

有趣。我们这里有核心动画。我通过非常艰难的方式了解到这一点，这意味着我可能正在从后台线程进行 UIKit 调用，但我不能这样做。最大的问题是在哪里以及如何进行。虽然说“你不应该从旧的后台线程调用 UIKit”可能很容易，但要知道 UIKit 调用到底是什么构成并不那么容易。正如您将在本例中看到的，这远非显而易见。

那么#2-1 的级别太低，没有任何实际用途。我认为。

我仍然不知道从哪里开始寻找内存泄漏。所以我做了我唯一能想到的事情。

阶段 3：返回 galore

建议我们有一个看起来像这样的调用树：

App start
    |
Some init
  |      \
A init   B init - Other case - Fourth case
   \     /              \
 Some case            Third case
     |
  Fifth case
   ...

应用程序生命周期的粗略轮廓。简而言之，我们有许多应用程序可以根据发生的情况采取的路径，并且每个路径都包含在不同位置调用的一堆代码。于是我拿出剪刀开始剪。我一开始就接近“应用程序启动”，然后慢慢地沿着线向十字路口移动，在那里我只允许一条路。

然后

// ...
[fooClass doSomethingAwesome:withThisCoolThing];
// ...

如果

// ...
return;
[fooClass doSomethingAwesome:withThisCoolThing];
// ...

在设备上安装该应用程序，将其关闭，使用 alt-tab 切换到 Instruments，按下 cmd-R，像猴子一样锤击该应用程序，寻找泄漏，并且在可能 10 个“周期”之后， 没有什么，我断定泄漏是在代码的更下方。可能在 fooClass 的 doSomethingAwesome: 中或在对 fooClass 的调用下面。

因此，我将 return 移至对 fooClass 的调用下方一步并再次测试。如果现在没有出现泄漏，那就太好了，fooClass 是无辜的。

此方法存在一些问题。

1. 内存泄漏对于何时暴露自己往往有点势利。可以这么说，你需要浪漫的音乐和蜡烛，并且在一处切断一端有时会导致内存泄漏决定根本不出现。我经常不得不返回返回，因为泄漏是在我添加以下行之后出现的：UIImage *a;（显然它本身不会泄漏）
2. 这真是令人痛苦对于一个大程序来说，速度又慢又累。尤其是当您最终不得不再次备份时。
3. 很难追踪。我不断地输入 // 17 14.48.25: 3 Leaks @ RSx10 ，这在英语中的意思是“July 17th, 14:48.25: 3 Leaks大众，当我重复选择该项目10次时”。应用程序。凌乱，但至少它让我清楚地看到我在哪里测试了东西以及结果是什么。

这个方法最终把我带到了处理缩略图的类的最底层。该类有两个方法，一个方法初始化事物，然后对一个单独的方法进行 [NSThread detachThreadWithSeparator:] 调用，该方法处理实际图像并将它们向右缩放后放入各个视图中尺寸。

有点像这样：

// no leaks if I return here
[NSThread detachNewThreadSelector:@selector(loadThumbnails) toTarget:self withObject:nil];
// leaks appear if I return here

但是如果我进入 -loadThumbnails 并逐步通过它，泄漏就会消失并以非常随机的方式出现。在一次广泛的运行中，我会出现泄漏，如果我将 return 语句移到下面，例如 UIImage *small, *bloated; 我就会出现泄漏。简而言之，非常不稳定。

经过更多测试后，我意识到如果我在应用程序中更快地重新加载内容，泄漏往往会更频繁地出现。经过几个小时的痛苦，我意识到，如果这个外部线程在加载另一个会话之前没有完成执行（从而创建第二个缩略图类并丢弃这个类），就会出现泄漏。

这是一个很好的线索。因此，我添加了一个名为 worldExists 的 BOOL，一旦新会话启动，它就设置为 NO，然后开始喷洒 - loadThumbnails 的 for 循环，

if (worldExists) [action]
if (worldExists) [action 2]
// ...

并确保在我发现 !worldExists 后立即退出循环。但泄漏仍然存在。

return 方法在非常不稳定的地方显示出泄漏。不经意间，就出现了。

因此，我尝试将其添加到 -loadThumbnails 的最顶部：

for (int i = 0; i < 50 && worldExists; i++) {
    [NSThread sleepForTimeInterval:0.1f];
}
return;

不管你信不信，但如果我在 5 秒内加载新会话，泄漏实际上就会出现。

最后，我在缩略图类的 -dealloc 中放置了一个断点。堆栈跟踪看起来像这样：

#0  -[Thumbs dealloc] (self=0x162ec0, _cmd=0x32299664) at /Users/me/Documents/myapp/Classes/Thumbs.m:28
#1  0x32c0571a in -[NSObject release] ()
#2  0x32b824d0 in __NSFinalizeThreadData ()
#3  0x30c3e598 in _pthread_tsd_cleanup ()
#4  0x30c3e2b2 in _pthread_exit ()
#5  0x30c3e216 in pthread_exit ()
#6  0x32b15ffe in +[NSThread exit] ()
#7  0x32b81d16 in __NSThread__main__ ()
#8  0x30c8f78c in _pthread_start ()
#9  0x30c85078 in thread_start ()

嗯...看起来还不错。如果我等到 -loadThumbnails 方法完成，跟踪看起来会有所不同：

#0  -[Thumbs dealloc] (self=0x194880, _cmd=0x32299664) at /Users/me/Documents/myapp/Classes/Thumbs.m:26
#1  0x32c0571a in -[NSObject release] ()
#2  0x00009556 in -[WorldLoader dealloc] (self=0x192ba0, _cmd=0x32299664) at /Users/me/Documents/myapp/Classes/WorldLoader.m:33
#3  0x32c0571a in -[NSObject release] ()
#4  0x000045b2 in -[WorldViewController setupWorldWithPath:] (self=0x11e9d0, _cmd=0x3fee0, path=0x4cb84) at /Users/me/Documents/myapp/Classes/WorldViewController.m:98
#5  0x32c29ffa in -[NSObject performSelector:withObject:] ()
#6  0x32b81ece in __NSThreadPerformPerform ()
#7  0x32c23c14 in CFRunLoopRunSpecific ()
#8  0x32c234e0 in CFRunLoopRunInMode ()
#9  0x30d620da in GSEventRunModal ()
#10 0x30d62186 in GSEventRun ()
#11 0x314d54c8 in -[UIApplication _run] ()
#12 0x314d39f2 in UIApplicationMain ()
#13 0x00002fd2 in main (argc=1, argv=0x2ffff5dc) at /Users/me/Documents/myapp/main.m:14

事实上，完全不同。不管你信不信，此时我仍然一无所知，但我终于明白发生了什么事。

问题如下：当我在缩略图加载器中执行 [NSThread detachNewThreadSelector:] 时，NSThread 保留该对象，直到线程耗尽。如果在加载另一个会话之前缩略图加载未完成，缩略图加载器上的所有保留都会被释放，但由于线程仍在运行，NSThread 使其保持活动状态。

一旦线程从 -loadThumbnails 返回，NSThread 就会释放它，它会达到 0 保留并直接进入 -dealloc...仍在后台线程中。

然后，当我调用 [super dealloc] 时，UIView 会乖乖地尝试从其超级视图中删除自身，这是后台线程上的 UIKit 调用。结果发生泄漏。

我想出的解决这个问题的解决方案是将加载器包装在另外两种方法中。我将其重命名为 -_loadThumbnails ，然后执行了以下操作：

[self retain]; // <-- added this before the detaching
[NSThread detachNewThreadSelector:@selector(loadThumbnails) toTarget:self withObject:nil];

// added these two new methods
- (void)doneLoadingThumbnails
{
    [self release];
}
-(void)loadThumbnails
{
    [self _loadThumbnails];
    [self performSelectorOnMainThread:@selector(doneLoadingThumbnails) withObject:nil waitUntilDone:NO];
}

说了这么多（我说了很多 - 对此感到抱歉），最大的问题是： 你如何计算这些奇怪的 -不经过上述所有步骤就可以解决问题？

在上述过程中我错过了什么推理？ 您在什么时候意识到问题出在哪里？我的方法中有哪些冗余步骤？我可以以某种方式跳过第 3 阶段（返回），或者减少它，或者提高它的效率吗？

我知道这个问题是模糊和巨大的，但这整个概念是模糊和巨大的。我不是要求你教我如何发现漏洞（我可以做到……这只是非常非常痛苦），我是问人们倾向于做什么来减少处理时间。问人们“你如何发现泄漏？”这是不可能的，因为有很多不同的种类。但我容易遇到问题的一种类型是与上面类似的类型，在实际应用程序中没有调用。

您使用什么流程来更有效地追踪它？

Answer 1

在上述过程中我错过了什么推理？

在多个线程之间共享 UIView 对象应该在您编写代码时就在您的脑海中敲响非常响亮的警钟。

Answer 2

将来，您可能会考虑看看其他内存泄漏搜寻工具 ，例如 MallocDebug。