除錯利器-----------------------DebugTrace for Windows簡介 (轉)

除錯利器-----------------------DebugTrace for Windows簡介 (轉)[@more@]

首先申明一下，貼這個貼子的目的之一是王婆賣瓜似的推銷子做的東東；梁歪一個目的呢就是希望和大家交流一下的技巧。:P  請到這裡22/html/detrace.htm"> 具體的說明在zip包內。為了能夠跟蹤需求，以及bug反映，請下載的使用者發一個到.">luon@hotmail.com   實在不行的話，在這下面籤個到留下你的mail地址，謝謝

 

作為一名C/C++員，你最大的苦惱是什麼？如何處理Debug版和release版本之間的差異？如何在realese版本里面進行除錯？如何更好地除錯實時程式，如何更好地除錯多線城程式，如何除錯GDI程式……:namespace prefix = o ns = "urn:schemas--com::office" />

我想作為一個有的程式設計師，對付這樣的問題，應該都有自己的一套方法。但是能不能夠把這些方法共享給大家，提供一個能夠普及的東東呢？本人一直很迷惑。現在有了，答案就是DebugTrace。

作為一名C/C++程式設計師，我最大的苦惱就是陣列越界訪問的問題，你的呢？

很多時候，對某個程式的除錯，不是我們平時的F9[設定斷點],F5[執行],F10[單步],F11[跳入]可以解決的。這個問題比較突出的比如GDI程式的除錯，鍵盤程式的除錯。當你按下鍵盤的時候，會觸發鍵盤訊息，但你移動滑鼠進行操作的後，會導致出現無效區域，從而觸發WM_PAINT的。如果被除錯此時正好就對這些訊息感興趣的話，問題就出現了。在這種情況下，會對你的除錯帶來一定的影響。怎門半才好呢？常見的除錯GDI的方法是雙顯示器或者，除錯。鍵盤除錯的話，用其它的輸入方式來除錯。這樣就出現了很多針對性很強的個別方法，我們能不能夠有其他通用一點的方法呢？對了！有人想到了，我們可以寫LOG&TRACE。這肯定是一個絕好的方法，有了這樣的方法，才使很多的程式設計師在debug的苦海里看到了一點微茫的希望。

但是是不是有了這樣的方法就一勞永逸了呢？其實問題遠遠不是如此。才僅僅是個開頭。

比如，想寫一些資訊到LOG檔案裡面去，可能會有如下的程式碼:

    char szBuffer[20];

  ZeroMemory(szBuffer,sizeof(szBuffer));

  fprintf(pFile, szBuffer，”[%d]The First Log Information”,1);

這段程式碼基本上正確，初看的時候還很順眼，但是有經驗的程式設計師卻可以一樣看出其中的問題。你看出來了嗎？問題在哪裡？問題出在了字元陣列szBuffer的長度上，發生了陣列的越界訪問，這樣的一段程式放在程式裡，無一是一顆炸彈，隨時會跳出來興風作浪。程式改進的方法就是加大陣列的長度。但是在實際的情況下，究竟緩衝區需要設定成多大呢？這個很難把握的，唯一的回答就是具體情況具體分析了。如果有一個程式裡面有很多的地方需要寫LOG呢?不會是滿篇都出現這樣的語句吧？這樣的程式碼，不僅執行不高，開發效率也不會高，還影響程式的可讀性。有人說，將buffer設定成全域性的，不錯的主意，可是這個緩衝區究竟要設多大呢？這確實是個問題，聰明的辦法是此路不通另闢坦途。

其實可能很多人都想到了，我們完全可以用C++的string來解決這個問題。當然這個問題是解決了，但是如果你想在debug版本和release版本之間稍有不通時怎麼辦呢？通常的辦法是適用預編譯指令，比如:

  #ifdef DEBUG

    char szBuffer[20];

  ZeroMemory(szBuffer,sizeof(szBuffer));

  fprintf(pFile, szBuffer，”[%d]The First Log Information”,1);

  #endif

大量的這樣的語句出現在程式中，不僅需要專門的的與編譯指令方面的知識，還會影響程式的可讀性，而且如果一不小心與編譯指令本身除了點問題的話，錯誤提示不能正確指示的。這反倒增加了麻煩。

解決之道呢？強烈推薦使用DebugTrace，J

有了寫LOG檔案之後，是不是就萬事大吉了呢？回答當然是否定的。請考慮多執行緒時候的情況。在多執行緒的情況下，會出現什麼樣的問題呢？首先是我們在往disk或者memeory寫檔案的時候會出現問題，試想如果有很多執行緒再同時往同一個地方寫，不會發生訪問衝突嗎？幸運的是在系列的大部分OS裡面，檔案I/O已經是非同步訪問了。這個不是問題，可是既然buffer是全域性的，如何保證buffer的訪問不發生衝突呢？這是必要用到線城間通訊與同步的技術，一個小小的寫LOG操作需要這麼複雜的東東來完成它，不做也罷~！

 還有問題，寫LOG的話，需要等待程式執行完畢了，才來驗證寫LOG的結果，這樣的操作實時性差，在有的裡面，需要實時地知道當前程式執行到什麼地方了。寫LOG有延時性的問題，怎麼辦呢？

用過的朋友都知道，在java裡面可以有一個很cool的東東java虛擬機器JVM,任何需要跟蹤除錯的資訊都可以print到JVM上賴進行檢查，這對除錯程式的程式設計師來講是在事太方便了。想不想再你的C/C++程式的除錯過程中也有這樣的東東呢？

想的話，不妨一試DebugTrace！

在windows系統裡面著一個虛擬的視窗叫做DebugWindow.使用過GWND，softice或者VC或其他開發工具自帶的除錯工具都用到了這些東東。習慣使用這些東東的程式設計師如何將自己寫的資訊寫到裡面去，在除錯的時候實時檢查呢？答案就在DebugTrace。

同時很多人也關心，如何將我的LOG資訊寫到系統的事件記錄器裡面去呢？這也是DebugTrace的一個功能哦。

對於程式設計師來講，除錯的目的是要找出程式裡面的bug。Bug的表現方式當然是在那個檔案的那一行。如何將這些也表現到你的明明白白地告訴你呢？對於多執行緒的程式，如何知道那條資訊，是那個執行緒寫出來的呢？尤其是多個執行緒同時使用同一個執行緒的時候呢？如果堆時間要求較高的話，如何作出細微的分析呢？……

答案就在DebugTrace。

目前的DebugTrace已經經過了好多實際專案的考驗。表現一直不錯。尤其在某個多執行緒SOCKET和另外一個COM的專案裡面表現一直不錯。

有句話叫做“國之利器，不可示人”，但是我覺得有了交流才會有提高。所以但願DebugTrace對你有所幫助。值得一試的。