Firefox memory usage and memory leak news
http://www.squarefree.com/2007/09/20/firefox-memory-usage-and-memory-leak-news/
※ 譯註：下面文章有點技術性，不過一般人應當能夠看得懂，一起來打擊 Firefox 的記憶體滲漏（http://forum.moztw.org/viewtopic.php?t=13637）吧！
許多 Mozilla 社群成員，包括自願者與 Mozilla Corporation 員工，都在幫忙減少 Firefox 的記憶體使用，並修復近來的記憶體滲漏臭蟲。但願，這些努力的結果將使得 Firefox 3 比 Firefox 2 使用更少的記憶體，尤其是它在使用數個小時後。
記憶體使用
Federico Mena-Quintero 遞交一個 patch 讓 Firefox 在 5 秒後拋棄已解壓縮的影像資料（decompressed image data，如 jpeg）（bug 296818，https://bugzilla.mozilla.org/show_bug.cgi?id=296818）。ImageLib 模組的所有者 Stuart Parmenter 在 bug 386377（https://bugzilla.mozilla.org/show_bug.cgi?id=386377）中試驗一種單一選項的（competing）構想，不過現在他計畫協助進行 Federico 的修補。這個 patch 將讓影像資料加入本文（text）所使用的、基於時間的（time-based）快取（http://preview.tinyurl.com/2ucpst）而非傳統以空間為界限（space-bounded）的快取（譯註：如 IE）。
Aaron 提議要有一個「about:memory」的頁面，顯示 Firefox 記憶體使用的故障（bug 392351，https://bugzilla.mozilla.org/show_bug.cgi?id=392351）。當筆者將臭蟲指給 Brendan Eich 看，他興奮地將此臭蟲分派給自己處理。
Eli Friedman 發現 nsFloatCache 不再是必需品，並且已將其盡量排除（bug 381385）。
記憶體滲漏
David Baron 替最新的臭蟲檢查一個 patch，這隻臭蟲會在 Linux 上貢獻RLk（http://preview.tinyurl.com/3xh92v），在這項測試歸零中（http://dbaron.org/log/2007-08#e20070804a）會使一票 XPCOM objects 滲漏。由於這項測試在 Tinderbox 上執行，回歸（regressions）似乎不會這麼快被注意到，即便它們不會將 Tinderbox 轉變成橘色（https://bugzilla.mozilla.org/show_bug.cgi?id=390916）。
Robert Sayre 創造一個 script 以隨機載入網頁，並觀察它們是否會導致滲漏。這些隨機 URL 來自於 Yahoo 目錄（http://random.yahoo.com/bin/ryl，偏好時間較久、排名較高的網頁）、 del.icio.us（偏好較新，較奇怪的網頁）與 AltaVista（偏好情色網頁）。這個 script 使用 trace-refcnt，同樣的測試被 RL 使用，來偵測滲漏；未來的版本可能使用 trace-malloc 以便捕捉額外的滲漏。Robert 利用這個 script 至少抓到 6 個不同的滲漏臭蟲，其中 3 個已經修復。詳見LeakingPages（http://wiki.mozilla.org/LeakingPages）與 bug 394517（https://bugzilla.mozilla.org/show_bug.cgi?id=394517）。
David Baron 創造一系列 patchs（http://preview.tinyurl.com/2rbxuo）以 cycle collector 協助對滲漏進行除錯。憑藉此碼，Firefox 的 DEBUG_CC builds（譯註：以不同方式編譯出來的程式版本），能在某一 object「預期將成為垃圾」卻不會被回收時提出警告，而且能詳加解釋為何它不會被回收。
Steve England 測試 top 500 web sites（http://preview.tinyurl.com/372cdp），發現二個滲漏。稍後，他測試 top 20 Firefox extensions（http://preview.tinyurl.com/3xvshf）發現其中有數個滲漏。
David Baron 錄下數個滲漏除錯畫面（screencasts，以數位方式記錄電腦螢幕的輸出，http://people.mozilla.com/~dbaron/leak-screencasts/），你能透過這些觀察 David Baron 如何對真正的滲漏進行除錯。
Kris Zyp 使用這種 watch 方法（http://preview.tinyurl.com/qoxc4
），在 JavaScript Engine 當中發現一個滲漏（bug 394709，https://bugzilla.mozilla.org/show_bug.cgi?id=394709）。
Igor Bukanov 對此很快速的進行回應，而且不只是對此臭蟲的 patch 而已，他還增加了一個滲漏偵測 patch（https://bugzilla.mozilla.org/show_bug.cgi?id=394853）讓人能夠對 JavaScript Engine 滲漏進行回歸測試（regression testing）。筆者要求他修改他的 patch，以讓筆者能使用 jsfunfuzz（http://www.squarefree.com/2007/08/02/introducing-jsfunfuzz/）測試 JavaScript Engine 滲漏，而他辦到了。（因此也讓筆者在 evalcx，http://preview.tinyurl.com/2pzm5m，中發現數個臭蟲，但沒有額外的滲漏。）
David Baron 獲得一堆 walking code，與多位修補者在 Mac 上工作，讓它能夠在 Mac 上使用 trace-malloc 與 refcount balancer（bug 336517，https://bugzilla.mozilla.org/show_bug.cgi?id=336517，bug 392118，https://bugzilla.mozilla.org/show_bug.cgi?id=336517）。
如何幫忙
你不一定得要是 C++ 程式設計師才能夠幫忙尋找 Firefox 當中的滲漏。
如果你是一位 Firefox 使用者，最簡單的方法就當 Firefox 關閉時，以 wrapped 上一個稱為 leak-gauge.pl（http://preview.tinyurl.com/jd4bd）的 script 的 trunk nightly build 來瀏覽。
如果它回報這份文件或視窗有滲漏，試著回想要該如何重現這種滲漏，然後發出臭蟲回報。
如果你是進階使用者，你可以做某些類似於 trace-refcnt 在做的事，它能夠偵測所有 reference-counted objects 的滲漏，不只是視窗與文件而已。以 .mozconfig 選項 "--enable-logrefcnt"（或 build debug）來 build Firefox 並且以 XPCOM_MEM_LEAK_LOG=2 來執行你的 build。當 Firefox 關閉時，它會列印出一份詳細但無法理解的摘要，指出哪些種類的 objects 滲漏。
如果你是 C++ 程式設計師，並且想要協助診斷或修補臭蟲，請看看 Performance:Leak_Tools（http://wiki.mozilla.org/Performance:Leak_Tools）以及 David Baron的 screencasts（http://people.mozilla.com/~dbaron/leak-screencasts/）並在 irc.mozilla.org 上的 #developers 伸出你的援手。
※ 相關報導：
＊ HTTP 內容掃描出現 Unicode 處理漏洞
＊ Firefox 漏洞大檢閱 655 項缺失 71 個潛在風險
＊ IE, Firefox 出現新零時漏洞
＊ 新惡意手段：從瀏覽器外掛到 GIF
＊ Firefox URI 臭蟲已修補
＊ 如何在六個字內當掉「IE」？
＊ Java Popups 危險無法擋
＊ 調查：網路像叢林／Apache 地位開始動搖
＊ 2006 作業系統漏洞總結報告
＊ 駭客發現 Adobe PDF 的嚴重零時漏洞
＊ 利用 dangling pointer 的新駭客手法
＊ 多核心 CPU 之攻擊
沒有留言:
張貼留言