基于异常处理机制的程序“故障—差错—异常/失效”传播机理分析

摘要：如何有效地获取具有代表性的差错数据进行差错注入仍是故障注入技术一个有待深入研究的问题。文中通过故障注入实验分析了程序的“故障-差错-异常”传播机理，说明了从异常层次进行程序错误行为分析及其差错数据收集的合理性。该研究为当前具有较大规模的、具有异常处理机制的程序进行差错数据的收集提供了新途径。

关键词：异常；故障注入；软件差错

中图分类号：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]。所以，当该类程序中的故障在激活之后，会有一定的几率被异常处理机制侦测，最终引起异常。这说明程序中异常可看作程序故障激活后的一种表现形式。该文通过以Ipbench作为实验负载，对其进行基于正交缺陷分类[1]（orthogonal defect classification， ODC）故障的故障注入实现，分析了具有异常处理机制的程序中故障激活后如何引起异常的发生，描述了该类程序中“故障-差错-异常/失效”的传播关系。

1 程序“故障-差错-异常/失效”机理分析

图1 在“故障-差错-失效”基础上考虑了异常处理环节

程序的“故障-差错-失效”过程已经得到了准确地描述[2]。在具有异常处理机制的程序中，故障激活后所生成的差错经传播后若被异常处理机制侦测，则异常发生。若对该异常处理不当，则可引起程序失效[3]，过程呈现“故障-差错-异常/失效”特征。所以，可将异常看作一般差错在程序中的一种表象。程序“故障-差错-异常/失效”过程如图1所示。

以Ipbench中的_validate_cell函数为例，结合ODC故障注入实验的实施过程，对“故障-差错-异常”传播机理进行分析，如下：

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.