当Leaks仪器没有显示时，如何调试内存泄漏？ [英] How to debug memory leaks when Leaks instrument does not show them?

问题描述

我有一个用Swift编写的iOS应用程序泄漏内存 - 在某些情况下应该释放一些对象，但事实并非如此。我通过简单地添加 deinit 这样的调试消息来了解这个问题：

  deinit {
 println（DEINIT：KeysProvider release）
} 
  

因此，在应该导致对象释放的此类事件之后，deinit消息应该出现在控制台中。但是，对于应该释放的某些对象，消息将丢失。仍然，Leaks Developer Tool没有显示任何泄漏。我如何解决这种情况？

解决方案

在Xcode 8中，您可以单击Debug Memory Graph按钮，（显示在屏幕底部）：

只需在左侧面板中识别您认为应该已取消分配的对象，它将显示对象图（显示在主画布上方）。这对于快速识别在相关对象上建立强引用的位置非常有用。从这里，你可以开始你的研究，诊断为什么那些强引用没有被解决（例如，如果有问题的对象有一个应该已经解除分配的其他东西的强引用，也可以查看该对象的图表，你可能会发现问题（例如强参考周期，重复计时器等）。

注意，在右侧面板中，我看到了调用树。我通过转动得到了它在方案设置中的malloc堆栈日志记录选项中：

无论如何，完成后，可以单击上面第一个屏幕快照右侧面板中堆栈跟踪中显示的相关方法调用旁边的箭头，您可以看到最初建立强引用的位置： / p>

上述内存诊断技术（及更多）在WWDC 2016的后半部分

WWDC 2012视频 iOS应用程序性能：内存

I have an iOS app written in Swift that is leaking memory - in certain situation some objects should be released but they are not. I have learnt about the issue by simply adding deinit debug messages like this:

deinit {
    println("DEINIT: KeysProvider released")
}

So, the deinit message should be present in console after such events that should cause the object to release. However, for some of the objects that should be released, the message is missing. Still, Leaks Developer Tool does not show any leaks. How do I solve such situation?

解决方案

In Xcode 8, you can click on the "Debug Memory Graph" button, in the debug toolbar (shown at the bottom of the screen):

Just identify the object in the left panel that you think should have been deallocated, and it will show you the object graph (shown in the main canvas, above). This is very useful in quickly identifying where the strong references were established on the object in question. From here, you can start your research, diagnosing why those strong references were not resolved (e.g. if the object in question has a strong reference from something else that should have been deallocated, look at that object's graph, too, and you may find the issue (e.g. strong reference cycles, repeating timers, etc.).

Notice, that in the right panel, I'm seeing the call tree. I got that by turning on the "malloc stack" logging option in the scheme settings:

Anyway, having done that, one can then click on the arrow next to the relevant method call shown in the stack trace in the right panel of the first screen snapshot above, and you can see where that strong reference was originally established:

The above memory diagnostic technique (and more) is demonstrated in the latter part of WWDC 2016 Visual Debugging with Xcode.

---

The traditional Instruments technique (especially useful if using older versions of Xcode) is described below, in my original answer.

---

I would suggest using Instruments' "Allocations" tool with the "Record Reference Counts" feature:

You can then run the app in Instruments and then search for your class that you know is leaking and drill in by clicking on the arrow:

You can then drill into the details and look at the stack trace using the "Extended Details" panel on the right:

In that "Extended Details" panel, focus on your code in black rather than the system calls in gray. Anyway, from the "Extended Details" panel, you can then drill into your source code, right in Instruments::

For more information and demonstrations in using Instruments to track down memory problems, please refer to:

• WWDC 2013 video Fixing Memory Issues
• WWDC 2012 video iOS App Performance: Memory

这篇关于当Leaks仪器没有显示时，如何调试内存泄漏？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！