|
由以上的程序,我們可以看到:在第5行分配內存時,忽略了字符串終止符"\0"所占空間導致了第8行的數組越界寫(Array Bounds Write)和第9行的數組越界讀(Array Bounds Read); 在第7行,打印尚未賦值的str2將產生訪問未初始化內存錯誤(Uninitialized Memory Read);在第11行使用已經釋放的變量將導致釋放內存讀和寫錯誤(Freed Memory Read and Freed Memory Write);最后由于str3和str2所指的是同一片內存,第12行又一次釋放了已經被釋放的空間 (Free Freed Memory)。
這個包含許多錯誤的程序可以編譯連接,而且可以在很多平臺上運行。但是這些錯誤就像定時炸彈,會在特殊配置下觸發,造成不可預見的錯誤。這就是內存錯誤難以發現的一個主要原因。
內存使用錯誤主要是指內存泄漏,也就是指申請的動態內存沒有被正確地釋放,或者是沒有指針可以訪問這些內存。這些小的被人遺忘的內存塊占據了一定的地址空間。當系統壓力增大時,這些越來越多的小塊將最終導致系統內存耗盡。內存使用錯誤比內存訪問錯誤更加難以發現。這主要有兩點原因:第一,內存使用錯誤是"慢性病",它的癥狀可能不會在少數、短時間的運行中體現;第二,內存使用錯誤是因為"不做為"(忘記釋放內存)而不是"做錯"造成的。這樣由于忽略造成的錯誤在檢查局部代碼時很難發現,尤其是當系統相當復雜的時候。
IBM Rational PurifyPlus是一組程序運行時的分析軟件。她包括了程序性能瓶頸分析軟件Quantify, 程序覆蓋面分析軟件PureCoverage,和本文的主角:程序運行錯誤分析軟件Purify。Purify可以發現程序運行時的內存訪問,內存泄漏和其他難以發現的問題。
同時她也是市場上唯一支持多種平臺的類似工具,并且可以和很多主流開發工具集成。Purify可以檢查應用的每一個模塊,甚至可以查出復雜的多線程或進程應用中的錯誤。另外她不僅可以檢查C/C++,還可以對Java或.NET中的內存泄漏問題給出報告。
程序運行時的分析可以采用多種方法。Purify使用了具有專利的目標代碼插入技術(OCI:Object Code Insertion)。她在程序的目標代碼中插入了特殊的指令用來檢查內存的狀態和使用情況。這樣做的好處是不需要修改源代碼,只需要重新編譯就可以對程序進行分析。
對于所有程序中使用的動態內存,Purify將它們按照狀態進行歸類。這可以由下圖來說明(來自[DEV205]):
參見本文中以上給出的代碼,在程序第5行執行后,str2處于黃色狀態。當在第7行進行讀的時候,系統就會報告一個訪問未初始化內存錯誤(Uninitialized Memory Read)。因為只有在綠色狀態下,內存才可以被合法訪問。
為了檢查數據越界錯誤(ABR,ABW),Purify還在每個分配的內存前后插入了紅色區域。這樣一來,超過邊界的訪問指令必定落在非法區域,從而觸發ABR或者ABW錯誤報告。這里需要指出一點。訪問未初始化內存錯誤UMR在某些情況下其實是合法的操作,例如內存拷貝。所以在分析報告時可以把UMR放到最后,或者干脆從結果中濾除。