☰

Firefox：查看特定 SVG 檔案會使系統無回應

tag-icon • tag-icon firefox memory freeze troubleshooting svg
Firefox：查看特定 SVG 檔案會使系統無回應

重要的：

目前，一些超級用戶常客正在嘗試縮小此問題的範圍和原因。我們目前正在尋找願意的志願者填寫表格這裡執行以下測試後：

  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 以及 trunk 的 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，行為也是相同的。我嘗試了我同事的機器，它有〜8000 MB RAM，同樣的情況發生（高內存使用率和1個處理器達到100％），當它達到〜4096 MB使用率時，會彈出一個對話框，要求殺死firefox（也許firefox被硬編碼為只使用 4096 MB？）。

如果我使用插件（quickjava）停用 javascript，我可以打開連結而不會出現問題。然而，在我同事的機器上，這不起作用：我嘗試了其他網站以確保 JS 被停用，但問題仍然存在。

是什麼原因造成的？

更新: 查看時出現問題這個SVG。

答案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 將問題隔離為這個特定的圖像。

相關內容