wingdb開發過程中遇到一個比較“頭疼”的bug

    我自持也寫了XX行的代碼，調試經驗也不可謂不強。但是最近遇到的這個bug，卻
著實讓我頭疼了一會...錯！不是一會，是3天啊！
    具體是這樣的，在開發windows下的gdb GUI調試環境時，使用thread PIPE與gdb mi
接口交互，在winodows 7下編寫代碼。上周五突然遇到一個問題:就是程序運行著就會突
然崩潰。馬上用ollydbg作為係統默認活動調試器，在崩潰後立即調試進程，發現錯誤點
隨機出現在主線程和PIPE READ線程中，而且指令在ntdll中出錯。並且看不到調用鏈，
不能回溯到我的程序中去，這說明不是我的程序直接引發的，而是“間接”引發的問題。
    奇怪的事來了，如果我用wingdb調試其他的pe文件不會出錯，隻有特定的那一個pe
文件必錯。比這個pe文件大或小的文件都不錯，單單這個pe文件會錯。而且隻在向gdb
mi發送特定的cmd時才會錯，使用其他cmd不會錯：
   

read_str_4a_cmd(&g_npp,"set disassembly-flavor intel\n",buf_tmp,&size,5000);  //err!

read_str_4a_cmd(&g_npp,"set\n",buf_tmp,&size,5000); //ok!

第一條指令返回的string長度要大於第二條。而且還有更鬱悶的事，在debug模式下
運行程序，啥錯都沒有，怎麼都不崩！調試最痛苦的事莫過如此....
    由於在windows7下調試安全保護不便的原因所以我嚐試在xp下調試，看能不能找
到問題根結。更奇怪的事來了，在雙核係統xp下沒有出錯！而且我原來的windows7
是單核的係統，我原以為可能是多線程同步的問題，這時覺得也不像。
    不能就此放過， 不能幻想是係統的bug，不是我的。並且念上10000句fxxk後，回去
肆虐TA發泄!我再一次回到windows7係統上，最小化出錯點（就像我不止一次在匯編及
C區說的那樣），編寫對應的單元測試，增加PRINT DEBUG語句，不是一條兩條的加，
而是幾十條的加。因為MinGW調試有限，所以換了調試也很有限的Code::Blocks，不過
比MinGW好點。使用VS 20xx的各位可能會暗自竊喜：叫你不用VS IDE。我承認在這個
方麵如果我最初用VS開發，也許調試起來就會快很多。也許吧...但我不能也不打算在回
到那個VS IDE中去，原因使用GCC的各位同仁自然懂得...
    言歸正傳，在用最簡化的UNIT TEST測試後，發現崩潰出在C庫函數free()裏。在經
曆了N多的反複遞進調試中後（就像在魔獸3中從zero開始建基地那樣），終於發現根本
問題所在:在N多的malloc和賦值和free中，一個賦值往末尾多賦了一個'\0',就是這一個
byte導致C heap鏈表被破壞，使得最終在某次的free中(主線程或PIPE Thread)發生崩潰
。然而為什麼隻有特定的文件，特定的指令才會崩潰，我想這個隻能感謝GOD讓我遇到
了那個出錯的文件，並且出錯了。因為這種錯誤和未初始化的變量一樣屬於“隨機”情況。
細心的朋友可能還不放過，會問:那在XP下為什麼不出錯？這個很簡單，因為win7的
安全性和魯棒性（如果我讓你產生了聯想，那麼我換一個詞:健壯性）比xp要高，
that's why!!!
    末了我想再說幾句，如果用NT的debug heap和若幹wingdb選項的話，我還用這麼費
勁嗎？？？嗚嗚嗚...不過沒事了，重要的是我會記住"調痛"，我可以GO ON了，嗬嗬。


                                                                                                         侯佩|hopy
                                                                                                   2011.08.08 1428