基于異常處理機制的程序“故障—差錯—異常/失效”傳播機理分析

摘要：如何有效地獲取具有代表性的差錯數據進行差錯注入仍是故障注入技術一個有待深入研究的問題。文中通過故障注入實驗分析了程序的“故障-差錯-異?！眰鞑C理，說明了從異常層次進行程序錯誤行為分析及其差錯數據收集的合理性。該研究為當前具有較大規模的、具有異常處理機制的程序進行差錯數據的收集提供了新途徑。

關鍵詞：異常；故障注入；軟件差錯

中圖分類號：TP311 文獻標識碼：A 文章編號：1009-3044（2014）30-7077-03

Analysis of Programs “fault-error-exception/failure” Process Based on Exception Control Flow

SUN Ya

（School of Software， Tongji University， Shanghai 201804， China）

Abstract： Its still a key question to fault-injection technique that how to effectively generate representative error set that emulates software fault. In this paper， the propagation process of “fault-error-exception” chain in program is analyzed with fault injection experiment， which rationalizes the point to analyze program erroneous behavior from the aspect of exception control flow. This research provides a new means to analyze the erroneous behavior and generate the valid error set for the large-scale program with exception handling mechanism automatically.

Key words： exception； fault injection； software error

故障注入技術通過人為地對軟件或計算系統注入故障，加速其失效而達到驗證目標軟件的容錯機制、評估軟件可靠性的目的[1]。如何獲取建立故障或差錯模型是該技術在實現過程中的關鍵[2]。對于軟件而言，在進行差錯注入之前，具有代表性的差錯集合獲取需要分析目標軟件的功能特性及其在故障激活后所表現出的錯誤行為[1-2]。但該過程需要分析大量故障或失效數據，周期很長。

程序的異常處理機制是提高軟件可靠性的重要手段之一。該機制通過異常的引發、捕捉及其錯誤處理代碼的執行，可將程序從錯誤狀態恢復到正常狀態，避免軟件失效的發生 [3]。所以，當該類程序中的故障在激活之后，會有一定的幾率被異常處理機制偵測，最終引起異常。這說明程序中異?？煽醋鞒绦蚬收霞せ詈蟮囊环N表現形式。該文通過以Ipbench作為實驗負載，對其進行基于正交缺陷分類[1]（orthogonal defect classification， ODC）故障的故障注入實現，分析了具有異常處理機制的程序中故障激活后如何引起異常的發生，描述了該類程序中“故障-差錯-異常/失效”的傳播關系。

1 程序“故障-差錯-異常/失效”機理分析

圖1 在“故障-差錯-失效”基礎上考慮了異常處理環節

程序的“故障-差錯-失效”過程已經得到了準確地描述[2]。在具有異常處理機制的程序中，故障激活后所生成的差錯經傳播后若被異常處理機制偵測，則異常發生。若對該異常處理不當，則可引起程序失效[3]，過程呈現“故障-差錯-異常/失效”特征。所以，可將異?？醋饕话悴铄e在程序中的一種表象。程序“故障-差錯-異常/失效”過程如圖1所示。

以Ipbench中的_validate_cell函數為例，結合ODC故障注入實驗的實施過程，對“故障-差錯-異?！眰鞑C理進行分析，如下：

1） 故障激活所生成的差錯直接引發異常，如圖2所示：<1>若第5、7行發生if語句丟失，則該控制故障使得raise語句執行而引發異常；<2>若第5行if語句的not關鍵詞丟失，則該控制故障使得raise語句在錯誤判斷下得到執行而引發異常；<3>若第4行中instance[‘cell_name]被錯誤的編寫成instance[‘cellname]，則該賦值故障使得cell_name值發生錯誤。該差錯可使得第5行if語句的判斷為True，讓原本不會被執行的raise語句得到執行而引發異常。

圖2 故障激活所生成的差錯直接引發異常程序示例

2） 故障激活所產生的差錯經過傳播后引發異常，如圖3所示：<1>若instance在傳入_validate_cell之前存在賦值故障，則該故障可導致第4行語句中的instance[‘cell_name]數據出錯，使得第5行if語句判斷為True，在raise語句得到執行后引發異常；<2>第7行中如果_cell_read_only函數存在接口故障，該故障激活后生成的差錯通過函數的返回值使得if語句判斷為True，在第8行raise語句執行后引發異常。

圖3 故障激活所產生的差錯經過傳播后引發異常程序

3） 無故障、無差錯情況下，外界輸入或外界資源違反軟件規格約束而導致異常的引發。異常處理機制是軟件錯誤處理的常用手段之一，對于在外界輸入或外界資源違反軟件規格約束的情況下，程序則利用該機制進行錯誤的偵測，并以異常的形式暴露該類錯誤的發生，若異常未被程序捕捉，則該類異常會導致程序崩潰[4]。文獻[4]對Android平臺上約800個應用組件進行了6，000，000次基于外界輸入的健壯性測試。由實驗數據表明，約10%的應用組件發生了崩潰且均由未捕捉異常造成。

2 實驗方案介紹

這一章節將介紹向Ipbench進行基于ODC的故障注入，并對該實驗結果進行分析。

2.1 Ipbench的故障注入方案

本文以分布式網絡基準程序Ipbench為對象，結合文獻[1]中具有代表性的ODC故障類型及其分布數據進行故障注入實驗方案的設計與實施。經過對Ipbench的分析，該程序的服務端與客戶端的總代碼量為1016行，總共具有348個故障注入點。根據文獻[1]中的ODC故障類型的分布特點，本故障注入方案中：賦值類故障為89個，控制類故障為76個，算法類故障為134個，接口類故障為14個，功能類故障為35個。

2.2實驗流程

根據上述的故障注入方案，在對目標程序進行故障注入之后需要重新啟動程序。在使用負載命令使得相關代碼得到執行后，注入的故障得到激活。通過對故障激活后的程序表現，將其與正常無故障情況下的程序輸出進行比較，然后判斷當前故障是否對程序引起失效，包括：錯誤輸出、程序掛起、程序崩潰。并且，記錄當前故障是否引起程序異常的發生、引起何種異常，以達到收集準確的實驗數據的目的。

2.3 實驗環境

本實驗在虛擬機上完成，操作系統為內核版本2.6.32的32位Linux，虛擬機硬件配置為1GB內存，Intel（R） Core（TM） i3-3217U@1.80GHz單核CPU。

3 實驗結果分析

表1 Ipbench與nova組件的故障注入實驗結果[Ipbench＼&ODC類型＼&正常輸出＼&錯誤輸出＼&程序掛起＼&程序崩潰＼&總數＼&異常＼&總數＼&異常＼&總數＼&異常＼&總數＼&異常＼&賦值＼&17＼&0＼&3＼&0＼&1＼&0＼&68＼&68＼&控制＼&6＼&0＼&3＼&0＼&2＼&0＼&65＼&65＼&算法＼&26＼&3＼&5＼&0＼&18＼&0＼&85＼&82＼&接口＼&1＼&0＼&0＼&0＼&2＼&0＼&11＼&11＼&功能＼&5＼&0＼&1＼&0＼&3＼&0＼&26＼&23＼&總數＼&55＼&3＼&12＼&0＼&26＼&0＼&255＼&249＼&引發率＼&5.5%＼&0%＼&0%＼&97.6%＼&]

由表1所示，Ipbench中共注入348個故障，其中255個故障導致了程序崩潰，且249次崩潰是由未捕捉異常引起。該程序缺乏合理的異常處理結構對各類異常進行捕捉、處理，成為了程序崩潰的主要原因。

實驗中差錯得到修正后，程序仍能正常輸出的原因包括但不限于：1）差錯相關的數據在被使用前重新得到初始化；2）差錯激活情況下的程序執行效果與無差錯情況下的程序執行效果相同；3）差錯所引起的異常被捕捉后，程序異常處理例程重新提供正常服務。

對于第一章節中1）和2）所描述的“故障-差錯-異?！眰鞑ミ^程而言，若排除差錯被修正后得到的正常輸入數據，Ipbench中由差錯引起異常的比例為97.6%。由于實驗規模的限制，該數據并不能代表所有程序的異常引發率，但可表明程序中一定比例的差錯能夠引起程序異常，且該引發率與程序異常處理結構實現的不同而不同。對于3）中的軟件健壯性問題，實際上是通過接口故障引入的，該類故障所生成的差錯具有不可忽視的異常引發率[4]。

4 結論

本文研究了軟件故障、差錯、異常之間的傳播機理，并通過故障注入實驗證明該機理分析結果的正確性和合理性。該研究也為具有異常處理機制的程序進行錯誤行為分析及其差錯數據收集提供了新的途徑。

參考文獻：

[1] Duraes J A，Madeira H S.Emulation of software faults： a field data study and a practical approach[J].IEEE Transactions onSoftware Engineering， 2006， 32（11）： 849-867.

[2] Christmansson J，Chillarege R.Generation of an error set that emulates software faults based on field data[C].Proceedings of the26th IEEE Symposium on Fault Tolerant Computing. Sendai， 1996： 304-313.

[3] Shah H B，Gorg C，Harrold M J.Understanding exception handling： Viewpoints of novices and experts[J].IEEE Transactions on Software Engineering， 2010，36（2）： 150-161.

[4] Amiya K Maji，Fahad A Arshad，et al. An empirical study of the robustness of Inter-component Communication in Android[C].Proceed-ings ofthe 42rd IEEE/IFIP International Conference on Dependable Systems and Networks. Boston ，2012： 1-12.

圖3 故障激活所產生的差錯經過傳播后引發異常程序

3） 無故障、無差錯情況下，外界輸入或外界資源違反軟件規格約束而導致異常的引發。異常處理機制是軟件錯誤處理的常用手段之一，對于在外界輸入或外界資源違反軟件規格約束的情況下，程序則利用該機制進行錯誤的偵測，并以異常的形式暴露該類錯誤的發生，若異常未被程序捕捉，則該類異常會導致程序崩潰[4]。文獻[4]對Android平臺上約800個應用組件進行了6，000，000次基于外界輸入的健壯性測試。由實驗數據表明，約10%的應用組件發生了崩潰且均由未捕捉異常造成。

2 實驗方案介紹

這一章節將介紹向Ipbench進行基于ODC的故障注入，并對該實驗結果進行分析。

2.1 Ipbench的故障注入方案

本文以分布式網絡基準程序Ipbench為對象，結合文獻[1]中具有代表性的ODC故障類型及其分布數據進行故障注入實驗方案的設計與實施。經過對Ipbench的分析，該程序的服務端與客戶端的總代碼量為1016行，總共具有348個故障注入點。根據文獻[1]中的ODC故障類型的分布特點，本故障注入方案中：賦值類故障為89個，控制類故障為76個，算法類故障為134個，接口類故障為14個，功能類故障為35個。

2.2實驗流程

根據上述的故障注入方案，在對目標程序進行故障注入之后需要重新啟動程序。在使用負載命令使得相關代碼得到執行后，注入的故障得到激活。通過對故障激活后的程序表現，將其與正常無故障情況下的程序輸出進行比較，然后判斷當前故障是否對程序引起失效，包括：錯誤輸出、程序掛起、程序崩潰。并且，記錄當前故障是否引起程序異常的發生、引起何種異常，以達到收集準確的實驗數據的目的。

2.3 實驗環境

本實驗在虛擬機上完成，操作系統為內核版本2.6.32的32位Linux，虛擬機硬件配置為1GB內存，Intel（R） Core（TM） i3-3217U@1.80GHz單核CPU。

3 實驗結果分析

表1 Ipbench與nova組件的故障注入實驗結果[Ipbench＼&ODC類型＼&正常輸出＼&錯誤輸出＼&程序掛起＼&程序崩潰＼&總數＼&異常＼&總數＼&異常＼&總數＼&異常＼&總數＼&異常＼&賦值＼&17＼&0＼&3＼&0＼&1＼&0＼&68＼&68＼&控制＼&6＼&0＼&3＼&0＼&2＼&0＼&65＼&65＼&算法＼&26＼&3＼&5＼&0＼&18＼&0＼&85＼&82＼&接口＼&1＼&0＼&0＼&0＼&2＼&0＼&11＼&11＼&功能＼&5＼&0＼&1＼&0＼&3＼&0＼&26＼&23＼&總數＼&55＼&3＼&12＼&0＼&26＼&0＼&255＼&249＼&引發率＼&5.5%＼&0%＼&0%＼&97.6%＼&]

由表1所示，Ipbench中共注入348個故障，其中255個故障導致了程序崩潰，且249次崩潰是由未捕捉異常引起。該程序缺乏合理的異常處理結構對各類異常進行捕捉、處理，成為了程序崩潰的主要原因。

實驗中差錯得到修正后，程序仍能正常輸出的原因包括但不限于：1）差錯相關的數據在被使用前重新得到初始化；2）差錯激活情況下的程序執行效果與無差錯情況下的程序執行效果相同；3）差錯所引起的異常被捕捉后，程序異常處理例程重新提供正常服務。

對于第一章節中1）和2）所描述的“故障-差錯-異?！眰鞑ミ^程而言，若排除差錯被修正后得到的正常輸入數據，Ipbench中由差錯引起異常的比例為97.6%。由于實驗規模的限制，該數據并不能代表所有程序的異常引發率，但可表明程序中一定比例的差錯能夠引起程序異常，且該引發率與程序異常處理結構實現的不同而不同。對于3）中的軟件健壯性問題，實際上是通過接口故障引入的，該類故障所生成的差錯具有不可忽視的異常引發率[4]。

4 結論

本文研究了軟件故障、差錯、異常之間的傳播機理，并通過故障注入實驗證明該機理分析結果的正確性和合理性。該研究也為具有異常處理機制的程序進行錯誤行為分析及其差錯數據收集提供了新的途徑。

參考文獻：

[1] Duraes J A，Madeira H S.Emulation of software faults： a field data study and a practical approach[J].IEEE Transactions onSoftware Engineering， 2006， 32（11）： 849-867.

[2] Christmansson J，Chillarege R.Generation of an error set that emulates software faults based on field data[C].Proceedings of the26th IEEE Symposium on Fault Tolerant Computing. Sendai， 1996： 304-313.

[3] Shah H B，Gorg C，Harrold M J.Understanding exception handling： Viewpoints of novices and experts[J].IEEE Transactions on Software Engineering， 2010，36（2）： 150-161.

[4] Amiya K Maji，Fahad A Arshad，et al. An empirical study of the robustness of Inter-component Communication in Android[C].Proceed-ings ofthe 42rd IEEE/IFIP International Conference on Dependable Systems and Networks. Boston ，2012： 1-12.

圖3 故障激活所產生的差錯經過傳播后引發異常程序

3） 無故障、無差錯情況下，外界輸入或外界資源違反軟件規格約束而導致異常的引發。異常處理機制是軟件錯誤處理的常用手段之一，對于在外界輸入或外界資源違反軟件規格約束的情況下，程序則利用該機制進行錯誤的偵測，并以異常的形式暴露該類錯誤的發生，若異常未被程序捕捉，則該類異常會導致程序崩潰[4]。文獻[4]對Android平臺上約800個應用組件進行了6，000，000次基于外界輸入的健壯性測試。由實驗數據表明，約10%的應用組件發生了崩潰且均由未捕捉異常造成。

2 實驗方案介紹

這一章節將介紹向Ipbench進行基于ODC的故障注入，并對該實驗結果進行分析。

2.1 Ipbench的故障注入方案

本文以分布式網絡基準程序Ipbench為對象，結合文獻[1]中具有代表性的ODC故障類型及其分布數據進行故障注入實驗方案的設計與實施。經過對Ipbench的分析，該程序的服務端與客戶端的總代碼量為1016行，總共具有348個故障注入點。根據文獻[1]中的ODC故障類型的分布特點，本故障注入方案中：賦值類故障為89個，控制類故障為76個，算法類故障為134個，接口類故障為14個，功能類故障為35個。

2.2實驗流程

根據上述的故障注入方案，在對目標程序進行故障注入之后需要重新啟動程序。在使用負載命令使得相關代碼得到執行后，注入的故障得到激活。通過對故障激活后的程序表現，將其與正常無故障情況下的程序輸出進行比較，然后判斷當前故障是否對程序引起失效，包括：錯誤輸出、程序掛起、程序崩潰。并且，記錄當前故障是否引起程序異常的發生、引起何種異常，以達到收集準確的實驗數據的目的。

2.3 實驗環境

本實驗在虛擬機上完成，操作系統為內核版本2.6.32的32位Linux，虛擬機硬件配置為1GB內存，Intel（R） Core（TM） i3-3217U@1.80GHz單核CPU。

3 實驗結果分析

表1 Ipbench與nova組件的故障注入實驗結果[Ipbench＼&ODC類型＼&正常輸出＼&錯誤輸出＼&程序掛起＼&程序崩潰＼&總數＼&異常＼&總數＼&異常＼&總數＼&異常＼&總數＼&異常＼&賦值＼&17＼&0＼&3＼&0＼&1＼&0＼&68＼&68＼&控制＼&6＼&0＼&3＼&0＼&2＼&0＼&65＼&65＼&算法＼&26＼&3＼&5＼&0＼&18＼&0＼&85＼&82＼&接口＼&1＼&0＼&0＼&0＼&2＼&0＼&11＼&11＼&功能＼&5＼&0＼&1＼&0＼&3＼&0＼&26＼&23＼&總數＼&55＼&3＼&12＼&0＼&26＼&0＼&255＼&249＼&引發率＼&5.5%＼&0%＼&0%＼&97.6%＼&]

由表1所示，Ipbench中共注入348個故障，其中255個故障導致了程序崩潰，且249次崩潰是由未捕捉異常引起。該程序缺乏合理的異常處理結構對各類異常進行捕捉、處理，成為了程序崩潰的主要原因。

實驗中差錯得到修正后，程序仍能正常輸出的原因包括但不限于：1）差錯相關的數據在被使用前重新得到初始化；2）差錯激活情況下的程序執行效果與無差錯情況下的程序執行效果相同；3）差錯所引起的異常被捕捉后，程序異常處理例程重新提供正常服務。

對于第一章節中1）和2）所描述的“故障-差錯-異?！眰鞑ミ^程而言，若排除差錯被修正后得到的正常輸入數據，Ipbench中由差錯引起異常的比例為97.6%。由于實驗規模的限制，該數據并不能代表所有程序的異常引發率，但可表明程序中一定比例的差錯能夠引起程序異常，且該引發率與程序異常處理結構實現的不同而不同。對于3）中的軟件健壯性問題，實際上是通過接口故障引入的，該類故障所生成的差錯具有不可忽視的異常引發率[4]。

4 結論

本文研究了軟件故障、差錯、異常之間的傳播機理，并通過故障注入實驗證明該機理分析結果的正確性和合理性。該研究也為具有異常處理機制的程序進行錯誤行為分析及其差錯數據收集提供了新的途徑。

參考文獻：

[1] Duraes J A，Madeira H S.Emulation of software faults： a field data study and a practical approach[J].IEEE Transactions onSoftware Engineering， 2006， 32（11）： 849-867.

[2] Christmansson J，Chillarege R.Generation of an error set that emulates software faults based on field data[C].Proceedings of the26th IEEE Symposium on Fault Tolerant Computing. Sendai， 1996： 304-313.

[3] Shah H B，Gorg C，Harrold M J.Understanding exception handling： Viewpoints of novices and experts[J].IEEE Transactions on Software Engineering， 2010，36（2）： 150-161.

[4] Amiya K Maji，Fahad A Arshad，et al. An empirical study of the robustness of Inter-component Communication in Android[C].Proceed-ings ofthe 42rd IEEE/IFIP International Conference on Dependable Systems and Networks. Boston ，2012： 1-12.