CN101706752B - 一种软件错误现场定位的方法及装置 - Google Patents

Abstract

本发明提供一种软件错误现场定位的方法及装置，其中的方法用于对嵌入式软件系统进行错误现场的定位，包括以下步骤：定位装置接收预定义的用于错误现场定位的待检测事件；所述定位装置通过监测所述嵌入式软件系统的运行判断所述待检测事件是否发生；所述定位装置在所述待检测事件发生时执行预定义的相应操作。本发明给出的技术方案通过在嵌入式软件系统运行过程中，不断检测预先定义的待检测事件的任务参数是否满足，从而在系统中可实施精确定位，定位精确大致是指令级，误差通常可控制在几个指令周期以内。本发明提出的技术方案需要在硬件的支持下进行芯片级的驱动开发，此外对软件系统的架构等没有任何限制，应用性较广。

Description

一种软件错误现场定位的方法及装置

技术领域

本发明涉及软件检测，尤其涉及一种在嵌入式软件系统中进行错误现场定位的方法及装置。

背景技术

随着科学技术的不断发展，自动化技术越来越多地受到关注。航空航天、通信、医疗器械、公共设施、家用电器、车载仪表等等各个领域越来越多地采用嵌入式系统来实现自动化技术，从而给用户带来更加安全、高效、稳定的服务。

然而任何软件系统都存在错误和异常，它们的存在可能会引起严重的后果。因此，在软件系统的生命周期中查找和消除错误和异常是一件至关重要的工作，它对软件系统的质量将产生不可估量的影响。在现代的软件工程中，为了尽量避免引入错误和异常或引入较少的错误和异常，研发人员都被要求按照严格的规范来进行软件的开发和设计，但是这并不能从根本上解决问题。

目前来说，软件系统开发的过程常用的调试手段比较单一，在测试阶段(单元测试、集成测试)除尽量考虑边界条件、扩大输入覆盖面外，对系统隐藏较深的错误和异常无法有效的定位和检测，如需要多个特定的条件同时满足才能触发的系统错误和异常，可能需要跑几百次甚至几万次或很长的时间才能出现，这样的情况常常让人无从下手，很难准确地分析错误原因。

在嵌入式系统的开发过程中，更是如此。由于嵌入式系统其具有的自身特点，例如开发界面不够友好、调试手段不充分、对错误和异常的反馈不及时等等，这常常导致调试过程异常繁琐、定位时间长、定位精度低，严重影响了软件开发的周期和效率，同时大大降低了软件质量。

发明内容

为了解决嵌入式系统运行过程中错误现场定位困难的问题，本发明的提供了一种软件错误现场定位的方法及装置，其中软件错误现场定位的方法用于对嵌入式软件系统进行错误现场的定位，包括以下步骤：

定位装置接收预定义的用于错误现场定位的待检测事件；

所述定位装置通过监测所述嵌入式软件系统的运行判断所述待检测事件是否发生；

所述定位装置在所述待检测事件发生时执行预定义的相应操作。

所述待检测任务参数包括：总线类型、触发方式、触发配置和触发类型。

所述判断所述待检测事件是否发生的步骤具体为：

所述定位装置在所述嵌入式软件系统的运行过程中判断所述待检测事件对应的待检测任务参数是否满足，如果满足，则指示所述待检测事件发生；

所述执行预定义的相应操作的步骤具体为：

所述定位装置在所述待检测事件发生时，产生特定异常中断或者将CPU挂起。

所述定位装置接收预定义的用于错误现场定位的待检测事件的步骤之后进一步包括：

所述定位装置向系统申请硬件资源；

所述定位装置在申请到硬件资源后，将所述待检测事件对应的待检测任务参数写入寄存器中。

本发明还提供了一种软件错误现场定位装置，包括：

接收模块，用于接收预定义的用于错误现场定位的待检测事件；

判断模块，用于通过监测嵌入式软件系统的运行判断所述待检测事件是否发生；

执行模块，用于在所述待检测事件发生时执行预定义的相应操作。

所述装置进一步包括：

申请模块，用于根据所述待检测事件，向系统申请硬件资源；

写入模块，用于在申请到硬件资源后，将所述待检测事件对应的待检测任务参数写入寄存器中。

所述接收模块通过后台工具实现，所述判断模块和所述执行模块通过CPU实现。

所述申请模块和所述写入模块通过前台实现。

所述待检测事件对应的待检测任务参数包括：总线类型、触发方式、触发配置和触发类型。

所述预定义的相应操作为产生特定异常中断或者将CPU挂起。

与现有技术相比，本发明具有以下有益效果：

本发明给出的技术方案通过在嵌入式软件系统运行过程中，不断检测预先定义的待检测事件的任务参数是否满足，从而在系统中可实施精确定位，定位精确大致是指令级，误差通常可控制在几个指令周期以内。本发明提出的技术方案需要在硬件的支持下进行芯片级的驱动开发，此外对软件系统的架构等没有任何限制，应用性较广。

附图说明

图1为本发明软件错误现场定位方法流程图；

图2为本发明软件错误现场定位装置结构示意图；

图3为本发明具体实施例的流程图。

具体实施方式

在传统的嵌入式系统中，通常是在仿真环境下进行软件系统的开发和测试，测试完成后投入到真实环境中运行。然而一旦在真实环境运行出现了故障，就不再具备错误现场还原的能力，很难进行调试。本发明提供了一种在嵌入式系统中利用错误预测和现场捕捉机制进行错误现场检测和定位的方法及装置，并给出了具体的实现方案。

下面结合附图对本发明的具体实施方式做进一步详细说明。

参考图1，图1为本发明软件错误现场定位方法流程图，包括以下步骤：

步骤1，定位装置接收预定义的用于错误现场定位的待检测事件；

待检测事件是自定义事件，对自定义事件的描述包括以下几个方面：

(1)总线类型：分为“数据总线”和“地址总线”。用于描述事件发生时CPU访问的内存地址是数据变量还是函数执行代码。

(2)触发方式：分为“点监控”和“范围监控”。用于描述事件发生时CPU访问的内存地址是某一特定的值还是某一范围内的值。

(3)触发配置：当触发方式为“点监控”时，为待检测的特定的内存地址；当触发方式为“范围监控”时，为待检测的内存起始地址和结束地址。

(4)触发类型：分为“读操作”和“写操作”。用于描述事件发生时CPU是“读内存”还是“写内存”。

步骤2，定位装置通过监测嵌入式软件系统的运行判断待检测事件是否发生；

判断的具体过程为：定位装置在嵌入式软件系统的运行过程中判断待检测事件对应的待检测任务参数是否满足，如果满足，则指示待检测事件发生。

步骤3，定位装置在待检测事件发生时执行预定义的相应操作。

定位装置在待检测事件发生时，产生特定异常中断或者将CPU挂起等预定义的操作。

本发明的定位方法要实现对错误现场的定位，需要在硬件资源充足的条件下实现，因此，本发明的定位方法在步骤1和2之间进一步包括：

步骤1.1，定位装置向系统申请硬件资源；

本步骤的具体实施过程为：

(1)判断当前系统中已成功配置的任务总数是否已达上限，若是则直接返回失败，否则继续执行(2)。

(2)判断当前系统中剩余的硬件资源种类和数量是否能满足任务需求，若不满足则直接返回失败，否则继续执行(3)。我们预先将系统的资源总数和已使用的资源数保存在全局变量中，称为资源状态图，当需要申请资源时，从资源状态图中进行查找。

(3)将本任务申请的硬件资源置为保留，并同时更新系统资源状态图。

这里需要说明的是(1)和(2)的执行过程并不分先后顺序。

步骤1.2，定位装置在申请到硬件资源后，将待检测事件对应的待检测任务参数写入寄存器中。

本发明的软件错误现场定位方法应用于软件错误现场定位装置，下面对软件错误现场定位装置进行详细说明。

参考图2，图2为本发明软件错误现场定位装置结构示意图，包括：

接收模块，用于接收预定义的用于错误现场定位的待检测事件；

判断模块，用于通过监测嵌入式软件系统的运行判断待检测事件是否发生；

执行模块，用于在待检测事件发生时执行预定义的相应操作。

进一步，为了保证本发明的装置能够正常运行，需要有充足的硬件资源的支持，因此，本发明的装置还包括：

申请模块，用于根据待检测事件，向系统申请硬件资源；

写入模块，用于在申请到硬件资源后，将待检测事件对应的待检测任务参数写入寄存器中。

下面通过一个具体实施例来说明如何在嵌入式系统运行过程中对嵌入式系统的错误现场进行定位。以下实施例需要在硬件的支持下进行芯片级的驱动开发，对软件系统的架构没有任何限制。

在对系统作集成测试的过程中，可以发现，单独执行测试任务A，测试样例正常通过，先执行测试任务B再执行测试任务A，同样的测试样例无法通过。而测试任务A和测试任务B并无任何相关性。通过简单的单步调试，我们发现全局变量gudTstAEnable被恶意篡改。gudTstAEnable用来表征测试任务A是否参与集成测试，从理论上分析，一旦所有测试用例已经定义完成，那么gudTstAEnable就不再变化。而测试任务是否参与测试、参与测试的执行顺序是在初始化时即配置完成的。这样的问题在嵌入式系统中是很常见的，但是通过单步调试进行定位的过程很繁琐，往往令人无从下手。下面说明如何使用本发明的装置来进行准确的错误现场定位。

接收模块的功能可以通过后台工具实现，申请模块和写入模块的功能通过前台实现，判断模块和执行模块的功能通过CPU实现。

前台承载整个软件系统的运行，负责满足用户自定义的具体功能的实现。后台工具可在不影响前台运行的前提下负责对前台状态的监控和检测。前台系统和后台工具之间可通过多种方式进行交互。在本实施例中，前后台通过TCP/IP协议进行通信。后台可主动向前台发送各种查询或检测命令，同时前台每间隔一定的时间主动将本系统的状态上报给后台。需要说明的是，前后台之间可存在多种交互方式，并不局限于TCP/IP协议，这些方案本质上并无区别。

参考图3，图3为本发明具体实施例的流程图。在具体执行定位操作之前，首先需要对前后台系统进行初始化，具体包括以下步骤：

步骤11，前台启动。

前台启动后，创建接收任务，等待后台工具发送的命令。前后台交互的命令包括：Init(后台请求前台初始化与调试相关的功能)、Setup Job(后台请求前台根据任务参数来进行检测任务的配置)、Release Job(后台请求前台释放某个特定的检测任务)、Close(后台请求前台关闭与调试相关的功能)等。

步骤12，后台向前台发送初始化命令。

步骤13，前台根据初始化命令将硬件寄存器、原有的检测任务信息等重置，并将执行结果反馈给后台工具。

上述步骤11～13为初始化过程，若初始化失败，则通常由于硬件异常导致，需要对硬件重新上电初始化。初始化完成后，执行步骤14，用户在后台工具的界面上配置待检测事件。本实施例中的待检测事件配置为“当全局变量gudTstAEnable被恶意篡改时产生系统异常中断，在异常中断的服务程序中将异常现场保存”，其具体的检测任务参数为：

1)总线类型：数据总线(gudTstAEnable是全局变量而不是函数代码)

2)触发配置：点监控(只关注gudTstAEnable定义的32bit地址)

3)触发方式：填入gudTstAEnable变量即可(后台可将变量名解析为变量地址)

4)触发类型：写操作(异常的写操作导致了程序的异常)

5)响应动作：中断(中断后前台将反馈异常事件产生时检测到的函数执行地址)

步骤15，待检测事件配置完成后，后台向前台发送Setup Job命令，前台根据该Setup Job命令向系统申请硬件资源。

本步骤具体为：

步骤151，判断当前系统中已成功配置的任务总数是否已达上限，若是则直接向后台返回失败消息，否则执行步骤152。

步骤152，判断当前系统中剩余的硬件资源种类和数量是否能满足任务需求，若不满足则直接向后台返回失败消息，否则执行步骤153。预先将系统的资源总数和已使用的资源数保存在全局变量中，称为资源状态图，当需要申请资源时，从资源状态图中进行查找。

步骤153，将本任务申请的硬件资源置为保留，并同时更新系统资源状态图。

步骤151和152的执行不分先后顺序，只要满足已成功配置的任务总数没有达到上限，以及当前系统中剩余的硬件资源种类和数量能够满足任务需求这两个条件，就能够成功申请到硬件资源。

步骤16，前台获得申请成功的硬件资源索引号，并将检测任务参数依次写入寄存器。

步骤17，启动本次检测任务，完成本次命令处理流程。

在本任务配置成功后直至本任务被删除或调试控制系统被卸载的整个系统运行期间，CPU将在执行过程中不断检测配置的条件是否满足，若满足即用户定义的事件已经发生，则执行步骤19，通过产生特定的中断来通知用户。此外，将检测到事件时的函数执行地址、当前正在执行的函数等信息上报给后台。从而用户可通过分析该部分内容来准确地获知程序发生错误前最后运行的状态。

在本实施例中，当gudTstAEnable变量被篡改时，CPU检测到前台配置到寄存器上的事件已经发生，从而执行预定义的处理动作，即产生特定的异常中断。在中断服务程序中，CPU读取产生异常时的PC地址为0xC0031A30。通过查询系统编译生成的map文件不难发现，0xC0031A30为函数TST_DMA_Copy的入口地址(后台自动完成该工作)，从而定位到B任务执行该函数时产生了异常。我们再定位到TST_DMA_Copy函数的代码，分析到该函数申请了较大的临时变量，而任务栈中剩下的存储空间已不能满足需求，从而导致任务栈溢出，最终导致在任务栈后的gudTstAEnable变量被冲。

通过本实施例，不难发现利用本发明的装置可以实现嵌入式系统在实际运行过程中出现错误时，自动对错误现场定位，还原错误现场，使原本较为繁琐的调试过程变得异常简单，大大提高了效率。

本发明的装置不止能够及时定位软件运行过程中产生的错误，在硬件资源不足和检测任务冲突等异常情况下，本发明的装置前台也能够将错误信息反馈给后台，使用户通过后台获取准确的错误信息。例如，当任务1已经占用了资源A，任务2也需要资源A时，会导致资源不足，此时，由于前台会根据检测任务参数去申请资源，因此，这种情况出现时，前台能够及时将错误原因反馈到后台，便于用户分析错误原因。再例如，在两个任务不能够同时存在的前提下，前台在配置检测任务参数时发现任务发生了冲突，便会及时将冲突原因反馈给后台。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (10)

1.一种软件错误现场定位的方法，其特征在于，所述方法用于对嵌入式软件系统进行错误现场的定位，包括以下步骤：

定位装置接收预定义的用于错误现场定位的待检测事件，其中，对所述待检测事件的描述包括：

总线类型：分为“数据总线”和“地址总线”，用于描述事件发生时CPU访问的内存地址是数据变量还是函数执行代码；

触发方式：分为“点监控”和“范围监控”，用于描述事件发生时CPU访问的内存地址是某一特定的值还是某一范围内的值；

触发配置：当触发方式为“点监控”时，为待检测的特定的内存地址；当触发方式为“范围监控”时，为待检测的内存起始地址和结束地址；

触发类型：分为“读操作”和“写操作”，用于描述事件发生时CPU是“读内存”还是“写内存”；

所述定位装置通过监测所述嵌入式软件系统的运行判断所述待检测事件是否发生；

所述定位装置在所述待检测事件发生时执行预定义的相应操作。

2.如权利要求1所述的软件错误现场定位的方法，其特征在于，所述判所述待检测事件是否发生的步骤具体为：

所述定位装置在所述嵌入式软件系统的运行过程中判断所述待检测事件对应的待检测任务参数是否满足，如果满足，则指示所述待检测事件发生；

所述执行预定义的相应操作的步骤具体为：

所述定位装置在所述待检测事件发生时，产生特定异常中断或者将CPU挂起。

3.如权利要求2所述的软件错误现场定位的方法，其特征在于，所述待检测任务参数包括：总线类型、触发方式、触发配置和触发类型。

4.如权利要求1所述的软件错误现场定位的方法，其特征在于，所述定位装置接收预定义的用于错误现场定位的待检测事件的步骤之后进一步包括：

所述定位装置向系统申请硬件资源；

所述定位装置在申请到硬件资源后，将所述待检测事件对应的待检测任务参数写入寄存器中。

5.一种软件错误现场定位装置，其特征在于，包括：

接收模块，用于接收预定义的用于错误现场定位的待检测事件，其中，对所述待检测事件的描述包括：

总线类型：分为“数据总线”和“地址总线”，用于描述事件发生时CPU访问的内存地址是数据变量还是函数执行代码；

触发方式：分为“点监控”和“范围监控”，用于描述事件发生时CPU访问的内存地址是某一特定的值还是某一范围内的值；

触发配置：当触发方式为“点监控”时，为待检测的特定的内存地址；当触发方式为“范围监控”时，为待检测的内存起始地址和结束地址；

触发类型：分为“读操作”和“写操作”，用于描述事件发生时CPU是“读内存”还是“写内存”；

判断模块，用于通过监测嵌入式软件系统的运行判断所述待检测事件是否发生；

执行模块，用于在所述待检测事件发生时执行预定义的相应操作。

6.如权利要求5所述的软件错误现场定位装置，其特征在于，所述装置进一步包括：

申请模块，用于根据所述待检测事件，向系统申请硬件资源；

写入模块，用于在申请到硬件资源后，将所述待检测事件对应的待检测任务参数写入寄存器中。

7.如权利要求5所述的软件错误现场定位装置，其特征在于，所述接收模块通过后台工具实现，所述判断模块和所述执行模块通过CPU实现。

8.如权利要求6所述的软件错误现场定位装置，其特征在于，所述申请模块和所述写入模块通过前台实现。

9.如权利要求5所述的软件错误现场定位装置，其特征在于，所述待检测事件对应的待检测任务参数包括：总线类型、触发方式、触发配置和触发类型。

10.如权利要求5所述的软件错误现场定位装置，其特征在于，所述预定义的相应操作为产生特定异常中断或者将CPU挂起。

Images