【技术实现步骤摘要】
本专利技术涉及软件开发，并且更具体地，涉及计算机程序的运行时存储器分析。
技术介绍
许多现代程序设计语言不支持防止运行时存储器访问错误的程序设计结构。运行时存储器访问错误可以包括、但不限于从未初始化的存储器读取或写入、超出所定义的数组的范围读取或写入、存储器泄漏、空闲存储器访问等。不支持防止这样的动作的构造的现代程序设计语言的一个例子是C或C++程序设计语言。当编译以C或C++编写的程序时，通常未检测到诸如以上所指出的运行时存储器访问错误。 举例来说，在C/C++内，开发者可能定义特定大小的数组并且然后访问超过该数组大小的元素。考虑图1中所示的代码实例。如所示出的，对a[21]的访问针对的不是由程序所分配的存储器部分，并且因此可能是堆(heap)上未分配的存储器或者是由另一段程序所分配的存储器。这样的动作是非法的，但却通常未被常规的C/C++编译器检测到。 然而，一些运行时分析工具，例如那些利用目标代码插入(OCI)技术的工具，可以检测这些类别的错误。OCI是在计算机程序的目标文件内插入校验指令的技术。具有这种插入其中的校验指令的程序被称作插装程序(instrumented program)。校验指令实现各种有关存储器使用的监控和/或跟踪功能。可以在访问(reference)存储器的程序指令之间插入校验指令，即监控读取和写入操作以及存储器分配和解除分配。 扩展与运行时存储器访问错误的检测有关的运行时分析工具的功能会是有益的。
技术实现思路
本文所公开的实施例提供了与计算机程序的运行时存储器分析有关的方法和制品(article of manufact...
【技术保护点】
一种分析计算机程序中运行时存储器访问错误的方法，所述方法包括：利用运行时分析代码插装所述计算机程序；检测所述已插装的计算机程序的运行时存储器访问错误；以及响应于检测所述运行时存储器访问错误，动态地设置监测点。
【技术特征摘要】
US 2005-12-27 11/306,391作为结论，但是可以认为考虑根据结合附图的描述将更好地理解本发明。如所需的，本文公开了本发明的具体实施例；然而，应当认识到，所公开的实施例仅是本发明的示范，其可以以各种形式实施。因此，不认为本文所公开的特定结构的和功能的细节是限制，而仅认为是用于权利要求的基本原理以及用于教导本领域的技术人员以实际上任何适当的具体结构来多样地使用本发明装置的代表性基本原理。此外，本文所使用的术语和惯用语并不打算限制而仅是提供本发明的可理解的描述。 本文所公开的实施例提供了用于在计算机程序中动态地设置监测点的技术。依照本文所公开的发明装置，用户或开发者可以设立各种条件。如果条件满足，就可以动态地创建监测点。此外，当满足设立的条件并且创建了监测点时就可以自动地执行一个或多个程序动作。 使用软件分析工具可以实现本文所描述的各种功能。例如，在一个实施例中，可以将本文所描述的各种功能实现为Rational PurifyPlus系列软件分析工具的一个或多个成员的扩展，其中来自纽约阿蒙克(Armonk)的国际商业机器公司(IBM)的Rational PurifyPlus系列软件分析工具是商业上可用的。PurifyPlus是为软件开发者和测试者提供运行时分析功能的计算机程序系列。一般而言，运行时分析指的是使用在执行处于测试中的程序期间所收集的数据来理解应用行为的实践。使用PurifyPlus可以分析的各种开发活动可以包括、但不限于本机C/C++应用中的存储器损坏检测和存储器剖析(memory profiling)、Java和.NET管理代码应用中的存储器剖析、识别慢的或无效的代码部分的性能剖析、代码覆盖分析以及运行时跟踪。 本文所公开的产品意图提供用于教导本领域的技术人员更好地理解本文所公开的发明装置的基本原理。然而，应当认识到，本发明可以实现为独立的应用、更大的应用的一部分或者以实际上任何适当的具体结构、计算机程序和/或其部分来实现。 图2是对理解本文所公开的实施例有用的示范性源代码。使用本文所描述的运行时分析工具来执行图2中所描述的程序会导致第10行所报告的“空闲存储器读”(FMR)错误的检测。FMR类型的运行时存储器访问错误指的是数组在被访问之前已经被释放的情形。 图3是关于根据图2所描述的错误由运行时分析工具所产生的示例输出。在所提供的关于运行时存储器访问错误的上下文信息的不同项目中，该输出指出了堆栈跟踪信息。堆栈跟踪信息指出使用对源于“calloc”内的“malloc”的调用来分配存储块，其中从“main”调用“calloc”，而从“start”调用“main”。 依照本发明的一个实施例，该上下文信息可以用于动态地创建和/或设置监测点。更具体地，该上下文信息可以与用户规定的信息，即指令的一个或多个属性进行比较。用户指定的属性指出动态地创建监测点的环境。如果上下文信息与用户指定的属性匹配，那么可以自动地设置监测点。按照可能由属性所指定的，可以执行另外的一个或多个程序动作。 监测点指的是能够指出指定的数据或存储器部分何时改变的监控程序或函数。例如，Purify中的监测点是通过监控程序执行时其进行加载和存储的地址来实现的。Purify可以报告有关读取、写入、分配、释放、进入函数入口范围以及离开函数出口范围的每次存储器访问的准确原因和结果。 在本发明的一个实施例中，用户指定的属性可以包括于运行时分析工具的配置文件内。例如，关于Purify，指令可以包括于指出特定环境的配置文件内，在该特定环境下监测点被自动地创建或者视具体情况而被调用。 这样的指令的例子可以是watch on error<error type><stack trace><re-start flag>。当在Purify的情况下将该指令放入配置文件中的时候，该指令引起针对由该指令的参数所指出的环境而设置或调用监测点。<errortype>属性指定了会引起调用监测点功能的特定类型的存储器访问错误。对于该属性来说可以指定的可能的运行时存储器访问错误可以包括、但不限于空闲存储器读错误、空闲存储器写错误、存储器泄漏错误、未初始化存储器读错误、数组边界读错误、数组边界写错误等。提供不同类型的运行时存储器访问错误的清单只是为了说明。同样地，本文所公开的实施例并不打算受限于所提供的实例。应当认识到，OCI工具能够识别的任何类型的运行时存储器访问错误都可以用作error type属性的可能值。 指令中的下一属性，<stack trace>属性可以指定为了调用监测点而要从运行时存储器访问错误检测的堆栈跟踪信息。例如，指令的堆栈跟踪信息可以指出下次检测对malloc的调用，其中从calloc调用malloc，从main调用calloc，从_start调用main，假定该指令的其他条件也满足，则自动地设置监测点。<re-start flag>属性指定了当调用监测点时是否要重新启动处于测试中的程序。在另一实施例中，可以提供另外的属性，其指出当设置监测点时是否要在调试器以及要使用的特定调试器中重新启动程序。 因此，当检测到运行时存储器访问错误的时候，可以将从运行时分析工具收集的信息，即根据图3所描述的上下文信息，与配置文件中所包括的用户指定的指令进行比较。如果检测到的运行时存储器访问错误的上下文信息与指令的属性匹配，则可以自动地创建对应于匹配指令的监测点。至于Purify运行时分析工具，视具体情况而定，可以将指定了从上下文信息或指令所提取的属性的指示插入到指示文件(directive file)。如所指出的，处于测试中的程序依照指令属性所指定的可选地可以随或不随调试器重新启动。 图4是说明依照本发明的一个实施例的运行时存储器分析方法400的流程图。例如，方法400可以开始于这样的状态，即在该状态下已将本文所讨论的各种指令中的一个或多个插入到诸如Purify的运行时分析工具的配置文件。如所指出的，指令的属性可以指定将要调用或设置监测点功能的环境。 因此，方法400可从步骤402开始，在步骤402中读取来自配置文件的指令。在步骤405中，基于OCI的运行时分析工具可以利用运行时存储器分析函数插装计算机程序。例如，Purify插装程序以自动地将每个存储器访问截取为其动态错误检测的一部分。可以将对运行时例程的一个或多个调用插入到程序，所述对运行时例程的一个或多个调用是运行时分析函数库部分，而不是处于测试中的程序的原始部分。可以在程序内包括、但不限于函数入口和/或出口点的位置插入这些函数以监控本文所描述的各种类型的存储器访问。在步骤410中，运行时分析工具可以读取来自指示文件的任何指示，所述指示文件已由于处于测试中的计算机程序的一次或多次先前的运行而被启用。可以利用已标识的指示实现存储器访问监控。 在步骤415中，可以执行插装程序。在步骤420中，可以进行关于是否遇到停止条件的确定。例如，程序可以自然地终止、遇到致命的故障或断点等。如果没有遇到停止条件，则该方法可以前进到步骤425。在步骤425中，可以进行关于是否遇到运行时存储器访问错误的确定。如果没有，则该方法可以返回到步骤415继续执行。如果检测到运行时存储器访问错误，则该方法可以前进到步骤430。 在步骤430中，可以通过OCI工具来收集上下文信息。例如，可以确定诸如引起运行时存储器访问错误的功能和/或模块的信息以及被访问的特定的存储器地址。还可以识别堆栈跟踪信息以及检测的存储器访问错误的类型，所述堆栈跟踪信息指定了通向造成运行时存储器...
还没有人留言评论。发表了对其他浏览者有用的留言会获得科技券。