我们正在追查内存泄漏

我们收到了许多关于 Safari 内存泄漏的报告，并希望修复其中大部分问题。这对 Safari 和其他 WebKit 应用程序的可用性来说是一个非常重要的因素。您可以提供帮助！方法如下：

查找泄漏

Mac OS X 开发者工具包含一个非常有用的内存泄漏检测程序。以下是使用方法：

1. 获取一个最新的 WebKit 构建版本，理想情况下是开发构建版本，因为它会关闭 WebKit 中各种自定义的内存分配器。
2. 将 MallocStackLogging 环境变量设置为 YES（在 bash 中，export MallocStackLogging=YES；在 tcsh 中，setenv MallocStackLogging YES）。
3. 使用 run-safari 运行 Safari。
4. 随意浏览一会儿。
5. 在命令行中，运行 leaks Safari。

此时，如果发现了内存泄漏，leaks 程序会告诉您有多少，并给出每个泄漏的堆栈跟踪。您可以将此报告以及导致泄漏的步骤描述，提交到Bugzilla。在标题开头加上“LEAK:”，以便于查找这些 Bug。

如果您想提交一份更好的 Bug 报告，请尝试通过特定的步骤来重现泄漏，并将其包含在 Bug 报告中。您还可以查看泄漏报告中的回溯信息，看看是否有看起来相同的泄漏。为每个看起来不同的泄漏单独提交一个 Bug 报告很有用，并且可以合并在不同网站上但看起来具有相同堆栈跟踪的泄漏。

修复泄漏

修复内存泄漏有点像一门玄学。泄漏检查器会告诉您泄漏的内存是在哪里分配的，但不会告诉您为什么它从未被释放。有时从代码检查中可以明显看出，某个特定的分配没有对应的释放调用。其他时候，事情会变得更棘手——特别是当涉及引用计数时。在这种情况下，您通常知道某些代码在没有释放的情况下多持有了引用，但很难确定是哪段代码。

对于这些情况，我经常发现一个有用的技巧。在 gdb 中启动应用程序。在适当的 ref 和 deref 方法上设置断点。然后，使用 gdb 的 commands 功能为这些断点设置命令 bt 10; cont。您将为每个 ref 和 deref 获得一个 10 帧的回溯，这通常足以找到那个没有配对的引用。

消灭所有泄漏

如果您想帮助查找和修复泄漏，并且需要更多建议，请在 freenode 上访问 #webkit。祝您追查愉快。