控制代碼洩露除錯
控制代碼洩露除錯（handles leak debug）
一、概述
造成控制代碼洩露的主要原因，是程序在呼叫系統檔案之後，沒有釋放已經開啟的檔案控制代碼。
對於控制代碼洩露，輕則影響某個功能模組正常執行，重則導致整個應用程式崩潰。在 windows系統中， gdi 控制代碼上限是 12000 個，user 控制代碼上限是 18000 個。
與 windows 系統的設定不同，linux 系統對程序可以呼叫的檔案控制代碼數做了限制，在預設情況下，每個程序可以呼叫的最大控制代碼數為 1024 個。超過了這個數值，程序則無法獲得新的控制代碼。因此，控制代碼的洩露將會對程序的功能失效造成極大的隱患。
理論上，我們程式設計時，1 個程序使用的控制代碼數建議不應該超過 1000。
二、分析
根據我們專案的測試經驗，通常統計出來的控制代碼圖形如下列 3 種：
1、平穩型
圖 2-1. 平穩圖
在程式執行當中，控制代碼被不斷地開啟關閉，因此統計圖形呈現平穩的鋸齒形。在程式執行後期，很多臨時開啟的控制代碼被逐漸關閉，總的控制代碼數量沒有隨著時間的推移而增加，因此該程式不存在控制代碼洩露。
2、峰值穩定型
圖 2-2. 峰值穩定圖
在該程式執行初期，程式開啟的控制代碼數量會隨著時間的推移而逐步增加。但是當執行一
段時間後，控制代碼數量會達到乙個相對平穩的狀態，大概 3500 左右。這個時候表明程式開啟
了很多臨時控制代碼，但是控制代碼數量相對穩定，也不存在控制代碼洩露問題。
3、遞增型
圖 2-3. 遞增圖
程式在執行當中，某一操作引起了程式開啟控制代碼數量逐步增加，而且沒有出現相對平穩的跡象，說明該程式可能存在控制代碼洩露，需要進一步分析是哪一部分的控制代碼存在洩漏，以及什麼操作會引起程式控制程式碼的洩露。
通過對程式控制程式碼數量進行取樣統計，並且繪製出相應的統計圖形，能夠以比較直觀的方式判斷在程式中是否存在控制代碼洩露。該方法基於程式要執行大量的測試用例，增加測試用例的覆蓋率，盡可能多的用測試用例觸發程式開啟和關閉控制代碼的操作，這樣才能發現潛在的控制代碼洩露 bug。對於如何能夠快速的發現控制代碼洩露**，我們將做進一步研究。
三、定位 （windbg 除錯）
1、執行程式
windbg 提供了圖形介面和命令列兩種執行方式。這裡介紹使用圖形介面的 windbg 來
除錯應用程式：
file->openexecutable->可以選擇乙個可執行檔案進行除錯。
file->attache to a process->可以選擇乙個執行中的程序，並對其進行除錯。
圖 3-1
2、啟動控制代碼操作的棧回溯
按下 f5 快捷鍵，第 1 次中斷程序執行，用!htrace -enable 命令開啟控制代碼檢測；htrace 提
供了進行控制代碼相關檢測的命令，可檢視 windbg 幫助文件。
圖 3-2
同時用 g 命令讓程式執行。
圖 3-3
3、抓取快照
第 2 次中斷程序執行，使用！htrace -snapshot 命令，獲得此時程序控制代碼的映象。並再次讓程式執行。
圖 3-4
4、執行程式，定位控制代碼洩露
第 3 次中斷程序執行，使用！htrace -diff 命令獲得當前控制代碼狀態與第 3 步 snapshot 映象控制代碼的差異；
圖 3-5
通過上面的棧回溯資訊，很清楚可以看到控制代碼開啟的地方。使用 lsa 命令可以定位到產
生控制代碼洩露的方法體**行，lsa handlew2!fun4+0x0000002e ：
圖 3-6
控制代碼洩露除錯
windbg除錯 控制代碼洩露
1 用c 寫乙個控制代碼洩露的樣例程式 include stdafx.h include void fun1 void void fun2 void void fun3 void void fun4 void int main int argc,char argv return 0 void fun...
控制代碼洩露問題追蹤
無論是在編寫windows程式還是linux程式，都可能存在控制代碼洩露的問題。在linux中一般來說乙個程序的fd使用是有上限的，可以使用ulimit命令進行上限檢視，當出現fd洩露的時候，可能會出現socket建立失敗,檔案打不開等問題。windows類似，本文主要闡述了對windows中的控制...
linux控制代碼洩露問題檢視
檢視與修改控制代碼 在linux系統中可以通過ulimit n檢視每個程序限制的最大控制代碼數，通過ulimit hsn 10240修改程序的最大控制代碼數。當控制代碼數目達到限制後，就回出現 too many files open 檢視程序占用的控制代碼數有幾種辦法 1 通過cat proc pi...