Firefox：查看特定的 SVG 文件会使系统无响应

Question

---

重要的：

一些 SuperUser 常客目前正试图缩小此问题的范围和原因。目前，我们正在寻求愿意志愿者填写表格这里进行以下测试后：

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 使用率持续高，则您的系统存在错误。否则，您就没有该错误。无论哪种情况，请相应地填写表格。

我们正在尝试缩小症状和原因的范围，以便更新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) 情况。此行为似乎仅限于具有 4 GB 或更少 RAM 的 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；而是 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 将问题隔离到此特定图像。