兩種追蹤方向#

定位問題來源通常有兩條路：從問題的表現處往上追 (bottom-up)，或從系統的頂端往下追 (top-down)。根據問題類型，其中一種通常比另一種更有效率。如果一條路走到死胡同，就換另一個方向。

由下往上 (Bottom-Up)：從問題的表現處出發#

當問題有明確的表現跡象時，由下往上追蹤最為合適。有三種常見情境：

程式崩潰 (Program Crash)#

• 在 debugger 中執行程式，或在崩潰後 attach debugger，或取得 memory dump
• 檢查崩潰點的變數值，尋找 null、損壞或未初始化的值
• 某些系統可透過特徵 byte pattern 辨識未初始化值（如 0xBAADF00D）
• 沿著 call stack 往上追，檢查不正確的參數
• 如果找不到原因，在可疑的計算點設置 breakpoint，逐步向上追蹤

程式凍結 (Program Freeze)#

• 在 debugger 中執行或 attach debugger，然後中斷執行
• 沿 call stack 往上移動，找到造成凍結的迴圈
• 檢查迴圈的終止條件，理解為何它永遠無法滿足

錯誤訊息 (Error Message)#

• 在原始碼中搜尋錯誤訊息文字（fgrep -r 是好幫手）
• 注意：在本地化軟體中，搜尋可能會定位到翻譯檔案（如 .po 檔）而非程式碼本身

#: ../share/extensions/gimp_xcf.py:43
msgid "An error occurred while processing the XCF file."
msgstr "Ha ocurrido un error al procesar el archivo XCF."

• 從翻譯檔案找到程式碼位置，在錯誤訊息出現前設置 breakpoint 或 log

搜尋非 ASCII 文字時，確保 command-line 的 locale 設定與原始碼的編碼一致（如 UTF-8）。

由上往下 (Top-Down)：從系統頂端出發#

當你無法明確定位與失敗相關的程式碼時，由上往下追蹤更合適。這通常是所謂的 emergent properties（浮現特性）——你無法將問題歸因於某個特定部分。例如：

• 效能問題：軟體太慢或佔用太多記憶體
• 安全問題：網頁被竄改
• 可靠性問題：服務無法提供預期功能

由上往下的做法是將整體分解為各個部分，逐一檢查每個部分對問題的貢獻。例如：

• 效能問題使用 profiling 工具
• 安全問題檢查 buffer overflow、code injection、XSS 等常見漏洞
• 可靠性問題逐一檢查 web service 的內外部依賴

重點回顧#

• 當失敗有明確的可辨識原因（如 crash、freeze、error message）時，採用由下往上的方式
• 當失敗難以明確定位（如效能、安全、可靠性問題）時，採用由上往下的方式