Firefox：查看特定 SVG 文件会导致系统无响应

Question

---

重要的：

几位超级用户常客目前正在尝试缩小该问题的范围和原因。我们目前正在寻找愿意的志愿者填写表格这里执行以下测试后：

1. 安装或启动最新版本的 Firefox（例如，24.x 或 25.x；测试版也很有趣）。
   
   
2. 使用平台的 Windows 任务管理器查看内存和 CPU 使用情况。您应该打开相应的任务管理器前你打开下面的链接。
   
   
3. 请保存 Firefox 浏览器中任何未完成的工作，因为它可能会崩溃。我们对任何信息丢失概不负责。
   
   
4. 在新选项卡中打开以下链接：http://openclipart.org/people/GR8DAN/showbizframe.svg
   
   
5. 观察加载图片前后 Firefox 进程的 CPU 和内存使用情况的变化。如果 Firefox 的内存使用情况有差异，之前和之后打开上述选项卡非常重要（1 GB 或更多），或者如果 Firefox 冻结或崩溃，或者如果你发现 CPU 使用率持续偏高，你的系统有 bug。否则，您没有遇到错误。无论哪种情况，请相应地填写表格。

我们正在尝试缩小症状和原因，以便更新Mozilla 错误追踪以便 Mozilla 开发人员能够解决该问题。我们之所以这样做，是因为这可能是一个影响范围广泛、优先级较高的问题；如果开始恶意使用图像嵌入功能，任何允许图像嵌入的网站都可能容易受到拒绝服务攻击，从而影响到访问该页面的相当一部分用户。

更新日期：2013/11/29：该漏洞已被隔离至以下位置：

• 它与平台无关。该错误已在 Linux、Mac 和 Windows 上重现。
  
  
• 该问题已在 AMD、Intel 和 Nvidia 显卡上重现。
  
  
• 它仅发生在 Firefox 及其衍生版本中。​​Chrome、IE、Opera 不受影响。
  
  
• 截至 2013 年 11 月 28 日，该问题已在 Firefox 25.0.1、Firefox 26 Beta、Firefox 27 Alpha 以及主干版本的 Nightly 版本中出现。
  
  
• 并非所有用户都会遇到 Firefox 崩溃或系统范围的内存不足 (OOM) 情况。此行为似乎仅限于 RAM 为 4 GB 或更少的 GNU/Linux 系统。
  
  
• 在 Firefox 27 Alpha 和 Nightly 中，行为与 Firefox 25 和 26 Beta 略有不同：在较新的两个版本中，如果您让图像加载较长时间（大多数系统上为 10 到 20 秒），高 CPU 和内存消耗最终会稳定下来。一旦“稳定下来”，内存和 CPU 状况就会恢复正常。但在较旧的两个版本中，只要您切换到正在呈现有问题的图像的选项卡，或者直到您完全关闭 Firefox 或关闭该选项卡，CPU 和内存状况就会持续存在。
  
  
• 几乎所有配备最新显卡驱动程序的系统都可以重现此问题。我们记录的系统中只有一个没有出现此问题的系统任何没有任何症状，并且它使用的是非常旧的图形驱动程序（大约 3 年）。这表明它不是任何特定硬件的问题，而是使用的非常旧的驱动程序中存在错误，奇怪的是，它可以防止出现缺陷行为。

---

原始问题：

我在 Fedora 19（内核 3.11.9-200.fc19.x86_64）上使用 Firefox firefox-25.0-3.fc19.x86_64。如果我打开此链接使用 Firefox 时，我的系统变得无响应。htop在第二个显示器上运行显示内存使用量大幅增加，我的 3954 MB RAM 立即全部用完，然后交换空间慢慢填满，其中一个处理器的使用率上升到 100%，然后系统变得无响应，鼠标变慢，htop刷新需要几十秒，等等。如果我终止 FF 进程，一切都会恢复正常。

即使在禁用插件的情况下以安全模式重新启动 FF，行为也是一样的。我试过我同事的机器，它有大约 8000 MB 的 RAM，也发生了同样的情况（高内存使用率，1 个处理器达到 100%），当使用率达到大约 4096 MB 时，会弹出一个对话框要求关闭 Firefox（也许 Firefox 被硬编码为仅使用 4096 MB？）。

如果我使用插件 (quickjava) 禁用 javascript，我可以打开链接而不会出现问题。然而，在我同事的机器上，这行不通：我尝试了其他网站以确保 JS 被禁用，但问题仍然存在。

是什么原因造成的？

更新：查看时出现此问题这个 SVG。

Answer 1

1. 这不是 JavaScript；事实上，您发布的链接呈现了许多复杂的可缩放矢量图形 (SVG) 文件。
2. Fedora 的硬件加速图形堆栈的错误率非常高，因此 Firefox 对图形堆栈的使用很可能会导致图形堆栈（在 Mesa、Xorg DDX 或内核中）出现错误。
3. 也有可能 SVG 实际上是在软件并且软件渲染器仍然存在缺陷。

让我们分而治之：

禁用硬件加速

在 FF 中，转到编辑 -> 首选项，单击高级，然后在常规选项卡下的浏览部分中，取消选中“在可用时使用硬件加速”。

现在再尝试同一个网站。如果你不出现 CPU/内存过载，那么我们就知道问题出在 2D Canvas GPU 加速上（Firefox 对其的使用，或者在后端图形堆栈中），或者出在 SVG 渲染器中。

如果你做如果在禁用硬件加速的情况下 CPU/内存过载情况相同，那么 SVG 解析器可能存在错误，这可能是纯软件造成的。尽管在这种情况下，我们可能也会在 Windows 上遇到此问题，但我们没有遇到（在 Windows 上的 FF 24.1.0 上进行了测试，它很慢，但不会像您的那样消耗所有 CPU 和 RAM）。

我怀疑 Mesa 存在某种内存泄漏。

还有几件事可以尝试

1. 进入about:supportFirefox，单击“将文本复制到剪贴板”，然后在此处发布（pastebin 等）。这将帮助我们这些熟悉问题空间的人确定您的硬件和图形堆栈的情况。
2. 进入about:memoryFirefox，勾选“详细”复选框，然后点击“测量”。如果你能做到这一点就太棒了刚过你转到有问题的页面 — — 如果你当时能够让 FF 做任何事情的话。
3. 从终端运行 Firefox，如下所示：LIBGL_DEBUG=verbose firefox -safe-mode。直接导航到发生 OOM 的站点。让它运行几秒钟（足以清楚地启动问题，但不要让它压垮您的系统）然后将其终止。在此处发布输出，以及 的输出dmesg。

这些内容将为我们提供更多调试信息，以便我们准确了解问题所在，但这些步骤中的大多数都集中在假设问题出在图形堆栈上。如果不是，那么这些步骤中的大多数都不会有帮助。

更新：我创建了一个原始 GitHub 链接它没有任何 javascript 或任何愚蠢的东西；它只是 SVG 的清单。如果您有缺陷的行为，它应该会崩溃，并且它消除了问题的所有其他可能来源。

更新 2：OP 将问题归结为这个特定的图像。