調(diào)試程序不可重現(xiàn)的bug

　　修復(fù)不可充實的bug比修復(fù)可重現(xiàn)的bug困難得多。通常，能了解到的信息很少，必須進(jìn)行大量猜測。不過，也有一些有幫助的策略：
　?。?）嘗試將不可重現(xiàn)的bug轉(zhuǎn)化為可重現(xiàn)的bug。通過充分的猜測，通常可以確定bug的大致位置。花一些時間嘗試重現(xiàn)bug。一旦有了可重現(xiàn)的bug，就可以使用前面描述的技術(shù)找到bug的根源。
　?。?）分析錯誤日志。如果程序根據(jù)前面的描述帶有錯誤日志生成的功能，那么這一點很容易實現(xiàn)。應(yīng)該篩查這些信息，因為bug出現(xiàn)之前記錄的任何錯誤都有可能會對bug本身有貢獻(xiàn)。如果幸運（或者程序?qū)懙煤茫绦驎涗浀绞诸^要處理的bug的準(zhǔn)確原因。
　?。?）獲取和分析跟蹤。如果程序帶有跟蹤輸出（例如之前描述的環(huán)形緩沖區(qū)），那么這一點很容易實現(xiàn)。在發(fā)生bug時，可能獲得一份跟蹤的副本。通過這些跟蹤，應(yīng)該能找到代碼中bug的正確位置。
　?。?）如果有的話，檢查內(nèi)存轉(zhuǎn)儲文件。有些平臺會在應(yīng)用程序異常終止時生成內(nèi)存轉(zhuǎn)儲文件。在Unix和Linux上，這些內(nèi)存轉(zhuǎn)儲文件稱為核心文件。每個平臺都提供了分析這些內(nèi)存轉(zhuǎn)儲文件的工具。例如，這些工具可以用來生成應(yīng)用程序的堆棧跟蹤信息，或查看應(yīng)用程序崩潰之前內(nèi)存中的內(nèi)容。
　?。?）檢查代碼。遺憾的是，這往往是檢查不可重現(xiàn)bug的根源唯一的策略。令人驚訝的是，這種方法往往奏效。檢查代碼時，甚至是檢查自己編寫的代碼時，如果帶著剛才發(fā)生的bug的視角，通?？梢哉业街昂鲆暤腻e誤。不建議花很長時間盯著代碼，而手工跟蹤代碼執(zhí)行路徑往往可以直接找到問題所在。
　?。?）使用內(nèi)存觀察工具，這類工具往往會警告一些并不總是會導(dǎo)致程序行為異常的內(nèi)存錯誤，但是這些問題可能是手頭上bug的根源。
　?。?）提交或更新bug報告。即使不能馬上發(fā)現(xiàn)bug的根源，如果再次遇到問題，這個報告會使描述前面做出的嘗試的有用記錄。
　　一旦找到了不可重現(xiàn)bug的根源，就應(yīng)該創(chuàng)建可重現(xiàn)的測試用例，并將其轉(zhuǎn)移至“可重現(xiàn)bug”類別。重要的是在實際修復(fù)bug之前重現(xiàn)這個bug。否則，怎么才能測試bug是否修復(fù)？調(diào)試不可重現(xiàn)bug的一個常見錯誤是在代碼中修復(fù)錯誤的問題。不能重現(xiàn)bug，也不知道是否真正地修復(fù)了這個bug，因此幾個月之后這個bug再次出現(xiàn)，就沒有什么可驚訝的。