# 15.9 調試提示 自我保護的程序,錯誤報告何其它的編碼技術只能幫助你這么多了,要單步跟蹤你的代碼,檢查每個變量的值,準確的告訴你你的程序有什么異常行為或者從代碼的什么地方退出,你還需要使用一個調試工具.因此,針對你的代碼,你至少需要維護兩套配置文件,一套調試版本何一套正式版本.調試版本將包含更多的錯誤檢測,將關閉編譯器的優化開關并且將包含調試程序需要的文件名,行號等調試信息.在調試模式,宏__WXDEBUG__總是被定義了,因此你可以使用這個宏來編寫那些僅存在于調試版本中的代碼,不過類似wxLogDebug這樣的函數,即使你沒有使用__WXDEBUG__宏將其包含,它仍然將在正式版本中被移除. 確實有很多人從來沒有使用過調試器,但是在你熟悉了這些工具以后,它將大大降低你的工作量.在windows平臺上,VC自帶了一個很不錯的調試器.如果你使用的是GCC,你可以使用GDB工具包,它工作在命令行模式下,你也可以使用一些集成了GDB的IDE環境.更多的信息可以參考附錄E,"wxWidgets的第三方工具". wxWidgets支持同時編譯多個版本.在windows平臺上,你可以給對應的Makefile傳遞BUILD=debug或 BUILD=release這樣的開關.如果你使用的是configure程序,你可以配置不同的版本編譯在不同的目錄,然后在各個版本中使用類似-- enable-debug或--disable-debug這樣不同的開關.某些集成開發環境出于各種各樣的原因不允許你的應用程序同時使用不同的配置文件,對于這樣的集成開發環境,作者的忠告是:不要使用它們. 調試X11錯誤 極少的情形下,wxGTK程序會由于X11的錯誤而崩潰,這時候你的應用程序將立即退出而不給你任何棧調用情況的打印,這種問題是非常難以跟蹤的,在這種情況下,你需要象下面代碼展示的那樣,增加一個錯誤處理函數: ``` #if defined(__WXGTK__) #include <X11/Xlib.h> typedef int (*XErrorHandlerFunc)(Display *, XErrorEvent *); XErrorHandlerFunc gs_pfnXErrorHandler = 0; int wxXErrorHandler(Display *display, XErrorEvent *error) { if (error->error_code) { char buf[64]; XGetErrorText (display, error->error_code, buf, 63); printf ("** X11 error in wxWidgets for GTK+: %s\n serial %ld error_code %d request_code %d minor_code %d\n", buf, error->serial, error->error_code, error->request_code, error->minor_code); } // 去掉下面的注釋以便將錯誤重定向道你的處理函數. #if 0 if (gs_pfnXErrorHandler) return gs_pfnXErrorHandler(display, error); #endif return 0; } #endif // __WXGTK__ bool MyApp::OnInit(void) { #if defined(__WXGTK__) // 安裝錯誤處理函數 gs_pfnXErrorHandler = XSetErrorHandler( wxXErrorHandler ); #endif ... return true; } ``` 現在,你的應用程序在遇到這樣的錯誤的時候,將會產生一個普通的段錯誤.如果你在啟動你的應用程序的時候傳遞了--sync參數,這個段錯誤將正好顯示在被傳遞了錯誤參數的X11函數的地方. 一個簡單有效的定位問題方法 如果你確實碰到了一個很難定位的問題,一個好的方法是使用盡量少的代碼來重現這個問題,你可以修改wxWidgets自帶的任何一個例子,增加一些代碼來重現你的問題,或者把你的代碼制作一份拷貝,逐段的去掉那些不影響這個錯誤的代碼,直至你可以準確的定位出是那些代碼導致了這個錯誤的產生.如果你認為這是wxWidgets本身的錯誤,把你修改后的導致問題出現的wxWidgets例子發送給wxWidgets社區,相信這個問題將被很快修正. 調試一個發布版本 某些情況下,你的應用程序可能在調試版本工作正常,而在正式版本中則工作不正常,這可能是由于編譯器使用的不同運行期庫文件的細微差別導致的.如果你正在使用的是VC,你可以創建一個和調試版本一模一樣的配置,但是卻定義了NDEBUG宏,這將使得你的代碼和wxWidgets和調試信息都具備,運行的時候卻使用的是發布版本的運行庫.這至少可以讓你確定是不是由于運行期庫的原因導致了這個問題. 通常當你發布你的應用程序的時候都將使用去除了所有調試信息的版本,但是有時候你的客戶會遇到一些在你的機器上很難重現的問題,,這時候你可能想給你的用戶發送一份調試版本的程序(在windows平臺上,通常你需要使用靜態編譯的方法以避免同時發送那些調試模式的動態鏈接庫).然后在你的客戶的機器上,可以使用一個叫做Dr.Watson的程序來運行你的包含調試信息的程序,在程序異常退出的時候,將會產生一個文件記錄當時的情況.參考你的編譯器的信息以及網上的教程來了解怎樣使用由Dr.Watson產生的這個文件來定位你的代碼中的異常. 如果你使用的是MinGW,你可以使用一個叫做Dr.MinGW的工具來在程序異常退出時候打印出一個有用的當前函數調用堆棧(當然, 如果你的代碼包含調試信息(打開了-g開關)的話).你可以從 http://www.mingw.org 下載這個工具,如果你的客戶有耐心并且很合作,你可以把這個工具發送給他們然后讓他們把產生的報告發送給你. 在Unix平臺上,調試版本的可執行文件可以產生一個core文件(這依賴于系統的設置,參考Unix命令ulimit的man手冊).你可以象你平時調試可執行文件那樣使用這個core文件,以便觀察程序退出時候的現場情況.然后,這個core文件可能會很大,你的客戶可能不大愿意發送給你這樣的一個core dump文件. 另外的一個替代方案是,你可以在你的程序中自己記錄程序的重要的執行情況.這方面你可以參考wxWidgets手冊中 wxDebugReport類相關的內容,這個類可以產生一個合適email給程序開發商的報告.類似的,你還可以使用來自http: //wxcode.sf.net的wxCrashPrint(for linux)或者來自 http://www.codeproject.com/tools/blackbox.asp 的BlackBox(for windows).