CN104572332A - 处理系统崩溃的方法和装置 - Google Patents

Abstract

本发明实施例提供的处理系统崩溃的方法和装置，包括：当系统崩溃后，系统开始执行崩溃处理流程；在崩溃处理流程执行的过程中，根据预设策略判断崩溃处理流程是否正确执行；若崩溃处理流程正确执行，则对看门狗进行喂狗操作，使崩溃处理流程执行完毕；若崩溃处理流程未正确执行，则触发看门狗对系统进行复位，使崩溃处理流程终止执行。通过发明提供的技术方案，当崩溃处理流程正确执行时可以使其执行完毕，当系统崩溃处理流程未正确执行时触发看门狗复位系统避免影响系统的可靠性。

Description

处理系统崩溃的方法和装置

技术领域

本发明实施例涉及计算机系统领域，尤其涉及一种处理系统崩溃的方法和装置。

背景技术

在计算机系统中，为了使系统在异常情况下能自动恢复，一般都会引入看门狗电路(以下均简称为看门狗)。看门狗工作的原理为：看门狗内部有一个计数器，当看门狗启动后，计数器自动开始计数，经过一定时间，计数器达到了设定的阈值，就会产生一个复位信号使系统重启。因此，为了使系统能够正常运行，需要在看门狗的计数器达到设定的阈值前进行计数器清零，该操作称为喂狗。

一般的，在系统中，看门狗的使用方法是：1、系统启动阶段，将看门狗配置为不使能；2、系统正常启动；3、系统启动完毕后，启动喂狗进程，该进程会周期喂狗；4、将看门狗配置为使能。之后，系统在正常运行中，喂狗进程能够确保看门狗的计数器被定期清零，系统能够顺利运行。一旦系统发生崩溃等故障，喂狗进程会因为故障而停止喂狗，看门狗会将系统复位。这种使用方法要求看门狗除提供基本功能外，还需要提供接口，使得系统能够将其禁用或使能。这导致了一个问题：如果系统在使能看门狗之前发生崩溃，则由于看门狗被禁用，无法确保系统复位。

在一些需要系统具备高可靠性的场景下，看门狗不提供禁用接口。例如，IMP706(美国IMP公司生产的微处理器监控芯片)，该芯片中的看门狗无法被禁用且看门狗的计数器的阈值也通常无法自行配置，能够确保任何情况下系统出现异常都能被正常复位。另外为确保系统及时复位，该芯片中的看门狗的复位时间设计的较短，复位时间为1.6秒。因此，这种看门狗在给系统带来高可靠性的同时，也为操作系统的设计带来了以下问题：系统崩溃后执行系统崩溃处理流程时如果超过看门狗复位时间，看门狗使得系统复位导致系统崩溃处理流程无法执行完毕，从而导致系统崩溃后无法收集到足够的信息，为后续分析系统崩溃原因带来很大障碍。

现有的解决上述问题的方案是：识别出系统崩溃处理流程中可能会使看门狗复位系统的操作，在系统代码中直接插入喂狗代码在看门狗复位系统前执行喂狗操作使得系统崩溃处理流程能够执行完毕。

上述现有技术方案存在以下问题：当系统崩溃处理流程本身有缺陷(例如系统崩溃处理流程陷入死循环但是喂狗操作一直在执行)，或者系统崩溃处理流程过长，则会导致系统很长时间不能被看门狗复位，影响系统的可靠性。

发明内容

本发明实施例提供的处理系统崩溃的方法和装置，能够解决由于系统崩溃处理流程本身有缺陷或处理时间过长导致系统长时间不能被看门狗复位进而影响系统可靠性的问题。

第一方面，本发明实施例提供一种处理系统崩溃的方法，所述方法包括：

当系统崩溃后，所述系统开始执行崩溃处理流程；

在所述崩溃处理流程执行的过程中，根据预设策略判断所述崩溃处理流程是否正确执行；

若所述崩溃处理流程正确执行，则对看门狗进行喂狗操作，使所述崩溃处理流程执行完毕；

若所述崩溃处理流程未正确执行，则触发所述看门狗对所述系统进行复位，使所述崩溃处理流程终止执行。

结合第一方面，在第一种可能的实现方式中，所述根据预设策略判断所述崩溃处理流程是否正确执行包括：

在所述崩溃处理流程开始执行时，读取所述系统的时钟源进行计时，经过预设时间后判断所述崩溃处理流程是否仍在执行；所述预设时间为预先通过测试得到的预期时间；

若所述崩溃处理流程执行完毕，则判定所述崩溃处理流程正确执行；

若所述崩溃处理流程仍在执行，则判定所述崩溃处理流程未正确执行。

结合第一方面，在第二种可能的实现方式中，所述根据预设策略判断所述崩溃处理流程是否正确执行包括：

当开始执行所述崩溃处理流程的代码中的指令时，通过性能监控单元(英文：Performance Monitor Unit，缩写：PMU)记录执行所述指令的条数，其中，每执行一条所述指令，所述性能监控单元PMU中的计数寄存器的值递增一次；判断所述计数寄存器的值递增的次数是否大于预先通过测试得到的预期指令条数；

若所述计数寄存器的值递增的次数小于或等于所述预先通过测试得到的预期指令条数，则判定所述崩溃处理流程正确执行；

若所述计数寄存器的值递增的次数大于所述预先通过测试得到的预期指令条数，则判定所述崩溃流程未正确执行。

结合第一方面，在第三种可能的实现方式中，所述根据预设策略判断所述崩溃处理流程是否正确执行包括：

当执行到所述崩溃处理流程的代码中的预设代码时，判断所述系统中的预设变量的值是否小于第一预设阈值；其中，每当所述系统在所述崩溃处理流程中执行一次喂狗操作，则将预设变量的值进行一次增加调整；

若所述预设变量的值小于所述第一预设阈值，则判定所述崩溃处理流程正确执行；

若所述预设变量的值大于或等于所述第一预设阈值，则判定所述崩溃处理流程未正确执行。

结合第一方面，在第四种可能的实现方式中，所述根据预设策略判断所述崩溃处理流程是否正确执行包括：

当执行到所述崩溃处理流程的代码中的预设代码时，判断所述系统中的预设变量的值是否大于第二预设阈值；其中，每当所述系统在所述崩溃处理流程中执行一次喂狗操作，则将预设变量的值进行一次减小调整；

若所述预设变量的值大于所述第二预设阈值，则判定所述崩溃处理流程正确执行；

若所述预设变量的值小于或等于所述第二预设阈值，则判定所述崩溃处理流程未正确执行。

结合第一方面的第三种或第四种可能的实现方式，在第五种可能的实现方式中，所述预设代码由用户在编写所述系统的代码时直接插入到所述系统的代码中；或者

所述预设代码是在所述系统初始化时根据所述系统的代码中的注入点利用动态注入技术注入到所述系统的代码中的，所述注入点是在所述系统初始化时读取配置信息获取的，所述配置信息包括：设备树中增加的节点、或命令行参数。

第二方面，本发明实施例提供一种用于处理系统崩溃的装置，所述装置包括：

崩溃处理模块，用于当系统崩溃后，开始执行崩溃处理流程；

判断模块，用于在所述崩溃处理模块执行所述崩溃处理流程的过程中，根据预设策略判断所述崩溃处理流程是否正确执行；

喂狗模块，用于若所述判断模块判定所述崩溃处理流程正确执行，对看门狗进行喂狗操作，使所述崩溃处理流程执行完毕；

复位模块，用于若所述判断模块判定所述崩溃处理流程未正确执行，则触发所述看门狗对所述系统进行复位，使所述崩溃处理流程终止执行。

结合第二方面，在第一种可能的实现方式中，所述判断模块包括：

计时单元，用于在所述崩溃处理模块开始执行所述崩溃处理流程时，读取所述系统的时钟源进行计时；

判断单元，用于当所述计时单元记录的时间达到预设时间后判断所述崩溃处理流程是否仍在执行；所述预设时间为预先通过测试得到的预期时间；若所述崩溃处理流程执行完毕，则判定所述崩溃处理流程正确执行；若所述崩溃处理流程仍在执行，则判定所述崩溃处理流程未正确执行。

结合第二方面，在第二种可能的实现方式中，所述判断模块包括：

指令计数单元，用于当开始执行所述崩溃处理流程的代码中的指令时，通过性能监控单元PMU记录执行所述指令的条数，其中，每执行一条所述指令，所述性能监控单元PMU中的计数寄存器的值递增一次；

判断单元，用于判断所述计数寄存器的值递增的次数是否大于预先通过测试得到的预期指令条数；若所述计数寄存器的值递增的次数小于或等于所述预先通过测试得到的预期指令条数，则判定所述崩溃处理流程正确执行；若所述计数寄存器的值递增的次数大于所述预先通过测试得到的预期指令条数，则判定所述崩溃流程未正确执行。

结合第二方面，在第三种可能的实现方式中，所述判断模块具体用于：

当所述崩溃处理模块执行所述崩溃处理流程的代码至所述崩溃处理流程的代码中的预设代码时，判断所述系统中的预设变量的值是否小于第一预设阈值；其中，每当所述系统在所述崩溃处理流程中执行一次喂狗操作，则将预设变量的值进行一次增加调整；若所述预设变量的值小于所述第一预设阈值，则判定所述崩溃处理流程正确执行；若所述预设变量的值大于或等于所述第一预设阈值，则判定所述崩溃处理流程未正确执行。

结合第二方面，在第四种可能的实现方式中，所述判断模块具体用于：

当所述崩溃处理模块执行所述崩溃处理流程的代码至所述崩溃处理流程的代码中的预设代码时，判断所述系统中的预设变量的值是否大于第二预设阈值；其中，每当所述系统在所述崩溃处理流程中执行一次喂狗操作，则将预设变量的值进行一次减小调整；若所述预设变量的值大于所述第二预设阈值，则判定所述崩溃处理流程正确执行；若所述预设变量的值小于或等于所述第二预设阈值，则判定所述崩溃处理流程未正确执行。

结合第二方面的第三种或第四种可能的实现方式，在第五种可能的实现方式中，所述装置还包括：

代码注入模块，用于在所述系统初始化时根据所述系统的代码中的注入点利用动态注入技术将所述预设代码注入到所述系统的代码中的，其中，所述注入点是在所述系统初始化时读取配置信息获取的，所述配置信息包括：设备树中增加的节点、或命令行参数。

本发明实施例提供的处理系统崩溃的方法和装置，当系统崩溃后，所述系统开始执行崩溃处理流程；在所述崩溃处理流程执行的过程中，根据预设策略判断所述崩溃处理流程是否正确执行；若所述崩溃处理流程正确执行，则对看门狗进行喂狗操作，使所述崩溃处理流程执行完毕；若所述崩溃处理流程未正确执行，则触发所述看门狗对所述系统进行复位，使所述崩溃处理流程终止执行。通过本发明提供的技术方案，当崩溃处理流程正确执行时可以使其执行完毕，当系统崩溃处理流程未正确执行时触发看门狗复位系统避免影响系统的可靠性。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例基于的通用计算机设备的基本架构图；

图2为本发明实施例提供的一种处理系统崩溃的方法的流程示意图；

图3为本发明实施例提供的一种处理系统崩溃的方法具体实施时的流程示意图一；

图4为本发明实施例提供的一种处理系统崩溃的方法具体实施时的流程示意图二；

图5为本发明实施例提供的一种处理系统崩溃的装置的结构示意图一；

图6为本发明实施例提供的一种处理系统崩溃的装置中的判断模块的结构示意图一；

图7为本发明实施例提供的一种处理系统崩溃的装置中的判断模块的结构示意图二；

图8为本发明实施例提供的一种处理系统崩溃的装置的结构示意图二；

图9为本发明实施例提供的另一种处理系统崩溃的装置的结构示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本发明实施例提供的技术方案基于通用计算机设备，该通用计算机设备可以是个人计算机设备、工业计算机设备或者单片机设备等等，本发明对此并不做限制。如图1所示，该通用计算机设备至少包括：CPU(可以是1个也可以是多个，图1中为2个)、内存、输入/输出(英文：Input/Output，缩写：I/O)设备、存储器以及看门狗。本发明实施例提供的技术方案可以用于一般的计算机系统，也可以用于嵌入式系统。

本发明实施例提供的一种处理系统崩溃的方法，如图2所示，该方法包括：

步骤101、当系统崩溃后，系统开始执行崩溃处理流程。

示例性的，以LINUX系统为例，当运行在硬件平台上的LINUX系统崩溃后，进入崩溃处理流程收集导致系统崩溃的相关信息。

步骤102、在崩溃处理流程执行的过程中，根据预设策略判断崩溃处理流程是否正确执行。

其中，预设策略可以是经过大量的系统测试确定的用于判断崩溃处理流程是否正确执行的策略。

步骤103、若崩溃处理流程正确执行，则对看门狗进行喂狗操作，使崩溃处理流程执行完毕。

示例性，如果经过步骤102判定崩溃处理流程正在正确执行，为了通过崩溃处理流程收集到足够的引起系统崩溃的相关信息，对看门狗进行喂狗操作以防止看门狗复位系统。

步骤104、若崩溃处理流程未正确执行，则触发看门狗对系统进行复位，使崩溃处理流程终止执行。

示例性的，如果经过步骤102判定崩溃处理流程未正确执行，崩溃处理流程有可能陷入了死循环，此时已无法继续收集引起系统崩溃的相关信息，为了保证系统的可靠性，触发看门狗对系统进行复位重启，终止执行崩溃处理流程。

需要说明的是，上述步骤102可以有很多种实施方式，在第一种可能的实施方式中，根据预设策略判断崩溃处理流程是否正确执行具体可以是：

在崩溃处理流程开始执行时，读取系统的时钟源进行计时，经过预设时间后判断崩溃处理流程是否仍在执行；预设时间为预先通过测试得到的预期时间；

若崩溃处理流程执行完毕，则判定崩溃处理流程正确执行；

若崩溃处理流程仍在执行，则判定崩溃处理流程未正确执行。

在第二种可能的实施方式中，根据预设策略判断崩溃处理流程是否正确执行具体可以是：

当开始执行崩溃处理流程的代码中的指令时，通过性能监控单元PMU记录执行指令的条数，其中，每执行一条指令，性能监控单元PMU中的计数寄存器的值递增一次；判断计数寄存器的值递增的次数是否大于预先通过测试得到的预期指令条数；

若计数寄存器的值递增的次数小于或等于预先通过测试得到的预期指令条数，则判定崩溃处理流程正确执行；

若计数寄存器的值递增的次数大于预先通过测试得到的预期指令条数，则判定崩溃流程未正确执行。

示例性的，上述的预期指令条数可以是技术人员对崩溃处理流程进行大量测试确定的崩溃处理流程的指令条数的经验值，PMU是处理器CPU中提供的一个硬件单元，它用于收集与CPU中的操作相关的事件。PMU中的计数寄存器(英文：Performance Monitor Counter，缩写：PMC)用于对CPU执行指令时发生的事件进行计数，例如当CPU执行一条指令，PMC的值加1。

在第三种可能的实施方式中，根据预设策略判断崩溃处理流程是否正确执行具体可以是：当执行到崩溃处理流程的代码中的预设代码时，判断系统中的预设变量的值是否小于第一预设阈值；其中，每当系统在崩溃处理流程中执行一次喂狗操作，则将预设变量的值进行一次增加调整；

若预设变量的值小于第一预设阈值，则判定崩溃处理流程正确执行；

若预设变量的值大于或等于第一预设阈值，则判定崩溃处理流程未正确执行。

在第四种可能的实施方式中，根据预设策略判断崩溃处理流程是否正确执行具体可以是：

当执行到崩溃处理流程的代码中的预设代码时，判断系统中的预设变量的值是否大于第二预设阈值；其中，每当系统在崩溃处理流程中执行一次喂狗操作，则将预设变量的值进行一次减小调整；

若预设变量的值大于第二预设阈值，则判定崩溃处理流程正确执行；

若预设变量的值小于或等于第二预设阈值，则判定崩溃处理流程未正确执行。

值得一提的是，上述第三种或第四种可能的实施方式中的预设代码可以由用户在编写系统的代码时直接插入到系统的代码中；或者该预设代码还可以是在系统初始化时根据系统的代码中的注入点利用动态注入技术注入到系统的代码中的，注入点是在系统初始化时读取配置信息获取的，配置信息包括：设备树中增加的节点、或命令行参数。

本发明实施例提供的一种处理系统崩溃的方法，当系统崩溃后，系统开始执行崩溃处理流程；在崩溃处理流程执行的过程中，根据预设策略判断崩溃处理流程是否正确执行；若崩溃处理流程正确执行，则对看门狗进行喂狗操作，使崩溃处理流程执行完毕；若崩溃处理流程未正确执行，则触发看门狗对系统进行复位，使崩溃处理流程终止执行。通过本发明提供的技术方案，当崩溃处理流程正确执行时可以使其执行完毕，当系统崩溃处理流程未正确执行时触发看门狗复位系统避免影响系统的可靠性。

为了使本领域技术人员能够更清楚地理解上述方法实施例中的第三种以及第四种可能的实施方式，下面对其进行详细说明：

在上述第三种以及第四种可能的实施方式中：预设代码可以是在系统初始化时根据系统的代码中的注入点利用动态注入技术注入到系统的代码中的，注入点是在系统初始化时读取配置信息获取的；预设代码也可以是由用户在编写系统的代码时直接插入到系统的代码中。前述第一种情况需要运行本发明实施例提供的技术方案的系统支持动态注入，第二种情况则是运行本发明实施例提供的技术方案的系统不支持动态注入的情况。

动态注入技术：是一种软件技术，它允许程序修改自身的代码，将一些功能注入进设计时预留的一些位置上，实现设计时未考虑的一些功能。它的一种实现原理是：在程序设计时，在代码中预先留出一些位置，用特定的指令(一般是nop指令，执行该指令不产生任何结果)填充；当需要进行代码注入时，将特定的指令替换成转移指令(例如BL指令)并将需要注入的代码载入内存，该转移指令用于转移到动态注入的代码处，动态加载的代码执行完毕后转移到原来特定指令后的代码继续执行。另一种实现原理是：将注入点原来的代码先保存到一个字典结构里，然后将注入点原来的代码替换成转移指令，该转移指令用于转移到动态注入的代码处，动态加载的代码执行完毕后，从前述字典结构取得之前保存的代码，通过模拟执行或实际执行使其产生效果，最后转移到原来被修改的代码之后的代码继续执行。

对于上述第一种情况，以一个包含有看门狗的嵌入式系统为例，该嵌入式系统上运行Linux系统，Linux系统的内核已经支持动态注入技术，并且在其代码中已经预留了很多注入点。本发明实施例提供的技术方案中预设代码的注入点由用户进行配置(即选择合适的注入点)生成配置信息，具体可以是通过在设备树(Linux内核读取设备树进行系统初始化)中增加节点，该节点用于描述注入点(一个或多个)，例如，注入点可以是printk函数(在Linux系统内核中运行的用于向控制台输出显示的函数)的入口处；或者还可以是通过命令行参数(用于向内核传递相关信息)描述注入点。另外值得一提的是，在设备树中增加的节点中还可以用于描述预设阈值，当然，也可以通过命令行参数向内核传递第一预设阈值或第二预设阈值，例如第一预设阈值可以是1000。

对于上述第二种情况，由于系统本身不支持动态注入，因此，用户在编写编写系统的代码时将预设的代码直接插入到系统的代码中，同时，也可以将选取的预设阈值直接编入系统的代码中。

示例性的，本发明实施例中的预设代码可以是一个feedex函数。如果预设代码属于第一种情况是动态注入的，可以增加一个字典结构，用于保存位于代码注入点上的原有代码，并增加一个feedex_caller函数，该函数用于调用feedex，并在调用后根据堆栈信息推导出自身的调用点，再从前述字典结构中找到原本位于调用点的代码，之后执行或模拟执行该代码，最后转移回调用点之后的代码处继续执行。在一种处理系统崩溃的方法中，预设变量记为counter，第一预设阈值记为max_coutner，counter的初始值小于max_coutner的值，当内核启动(即系统初始化)时，按照正常顺序加载内核，在内存初始化完毕后，解析如前所述的设备树和/或命令行参数获取feedex函数的插入点以及max_coutner的值，将插入点处的代码替换为BL指令，使其转移至feedex_caller函数，将调用点和被替换的代码存入前述字典结构，并将预设变量coutner的值置为初始值，例如max_coutner取1000，coutner的初始值取0。在另一种处理系统崩溃的方法中，预设变量也可以记为counter，第二预设阈值记为min_coutner，counter的初始值大于min_coutner的值，当内核启动(即系统初始化)时，按照正常顺序加载内核，在内存初始化完毕后，解析如前所述的设备树和/或命令行参数获取feedex函数的插入点以及max_coutner，将插入点处的代码替换为BL指令，使其转移至feedex_caller函数，将调用点和被替换的代码存入前述字典结构，并将预设变量coutner的值置为初始值，例如min_coutner取1000，coutner的初始值取2000。

另外，值得一提的是，第一种情况中由于是动态注入的方式并且注入点是在系统本身提供的注入点中选取的，相比第二种情况中直接插入代码的方式，后续对系统进行维护比较容易，并且换由其他用户对系统进行维护时也可以根据系统自身的注入点找出动态注入的预设代码。在本发明实施例提供的技术方案中执行至预设代码后的喂狗操作是通过使CPU执行指令通过I/O接口将看门狗的计数器清零来完成，本发明实施例提供的技术方案中的预设代码也不是现有技术方案中的喂狗代码。

对于上述实施例中第三种可能的实施方式，假设预设变量的初始值取为0，第一预设阈值取为1000，将对预设变量的值进行一次增加调整的操作可以有多种实现方式，例如对预设变量的值乘以一个正整数或者对预设变量的值加一个正整数等等方式，这里为了方便说明，将对预设变量的值进行一次增加调整的操作假设为对预设变量的值加1。

如图3所示，上述实施例中第三种可能的实施方式在具体实施时可以具体包括：

步骤301、系统开始运行并启动喂狗进程。

具体的，当系统正常运行时，喂狗进程会按照设定好的时间间隔周期性的喂狗。

步骤302、执行系统的代码。

步骤303、判断系统是否正常。

需要说明的是，预设代码具体是插入到系统崩溃流程的代码中的，系统崩溃流程的代码属于系统的代码，因此，在系统正常运行，执行系统的代码时也可能会执行至预设代码。例如预设代码为feedex函数，注入点为printk函数的入口处时，系统正常运行时也需要调用printk函数，因此也会调用到feedex函数。

当系统正常运行且满足喂狗进程的喂狗条件时，则执行步骤304；当系统崩溃进入系统崩溃处理流程后，执行系统的代码至预设代码时，执行步骤305；当系统正常运行，执行系统的代码至预设代码时，执行步骤305。

步骤304、调用喂狗进程进行喂狗，将预设变量的值置为0并转到步骤302。

需要说明的是，步骤304中所述转到步骤302是指执行系统正常运行时的系统代码。

步骤305、判断系统中的预设变量的值是否小于1000。

步骤306、若预设变量的值小于1000，则将预设变量的值加1并进行喂狗，并转到步骤302。

需要特别说明的是，步骤306中的喂狗操作是系统使CPU执行指令通过I/O接口将看门狗的计数器清零完成的，并不是通过喂狗进程完成的。另外，上述步骤306所述转到步骤302后分两种情况：当系统正常运行时，所述转到步骤302是执行系统正常运行时的系统代码；当系统崩溃后执行系统崩溃流程时，所述转到步骤302表示崩溃处理流程正确执行，继续执行系统崩溃流程的代码中的预设代码后续的代码也即继续执行崩溃处理流程。

步骤307、若预设变量的值大于或等于1000，则转到步骤302。

需要说明的是，上述步骤307中所述转到步骤302后分两种情况：当系统正常运行时，所述转到步骤302是执行系统正常运行时的系统代码；当系统崩溃后执行系统崩溃流程时，所述转到步骤302表示崩溃处理进程未正确执行，继续执行系统崩溃流程的代码中预设代码后续的代码也即触发看门狗对系统进行复位，使崩溃处理流程终止执行。

对于上述实施例中第四种可能的实施方式，假设预设变量的初始值取为2000，第二预设阈值取为1000，将对预设变量的值进行一次减小调整的操作可以有多种实现方式，例如对预设变量的值除以一个正整数或者对预设变量的值减去一个正整数等等方式，这里为了方便说明，将对预设变量的值进行一次减小调整的操作假设为对预设变量的值减2。

如图4所示，上述实施例中第四种可能的实施方式在具体实施时可以具体包括：

步骤401、系统开始运行并启动喂狗进程。

具体的，当系统正常运行时，喂狗进程会按照设定好的时间间隔周期性的喂狗。

步骤402、执行系统的代码。

步骤403、判断系统是否正常。

需要说明的是，预设代码具体是插入到系统崩溃流程的代码中的，系统崩溃流程对应的代码属于系统的代码，因此，在系统正常运行，执行系统的代码时也可能会执行至预设代码。例如预设代码为feedex函数，注入点为printk函数的入口处时，系统正常运行时也需要调用printk函数，因此也会调用到feedex函数。

当系统正常运行且满足喂狗进程的喂狗条件时，则执行步骤404；当系统崩溃进入系统崩溃处理流程后，执行系统的代码至预设代码时，执行步骤405；当系统正常运行，执行系统的代码至预设代码时，执行步骤405。

步骤404、调用喂狗进程进行喂狗，将预设变量的值置为2000并转到步骤402。

需要说明的是，步骤404中所述转到步骤402是指执行系统正常运行时的系统代码。

步骤405、判断系统中的预设变量的值是否小于1000。

步骤406、若预设变量的值大于1000，则将预设变量的值减2并进行喂狗，并转到步骤402。

需要特别说明的是，步骤406中的喂狗操作是系统使CPU执行指令通过I/O接口将看门狗的计数器清零完成的，并不是通过喂狗进程完成的。另外，上述步骤406所述转到步骤402后分两种情况：当系统正常运行时，所述转到步骤402是执行系统正常运行时的系统代码；当系统崩溃后执行系统崩溃流程时，所述转到步骤402表示崩溃处理流程正确执行，继续执行系统崩溃流程的代码中的预设代码后续的代码也即继续执行崩溃处理流程。

步骤407、若预设变量的值小于或等于1000，则转到步骤402。

需要说明的是，上述步骤407中所述转到步骤402后分两种情况：当系统正常运行时，所述转到步骤402是执行系统正常运行时的系统代码；当系统崩溃后执行系统崩溃流程时，所述转到步骤402表示崩溃处理进程未正确执行，继续执行系统崩溃流程的代码中预设代码后续的代码也即触发看门狗对系统进行复位，使崩溃处理流程终止执行。

综上所述，对于上述方法实施例中的第三种或第四种可能的实施方式，由于引入了预设变量，并通过预设变量记录崩溃处理流程中系统喂狗操作的次数，当预设变量的值不满足设定的条件时，触发看门狗对系统进行复位，有效解决了由于系统崩溃处理流程本身有缺陷或处理时间过长导致系统长时间不能被看门狗复位进而影响系统可靠性的问题。

本发明实施例提供的一种用于处理系统崩溃的装置10，如图5所示，该装置包括：

崩溃处理模块11，用于当系统崩溃后，开始执行崩溃处理流程；

判断模块12，用于在崩溃处理模块11执行崩溃处理流程的过程中，根据预设策略判断崩溃处理流程是否正确执行。

喂狗模块13，用于若判断模块12判定崩溃处理流程正确执行，对看门狗进行喂狗操作，使崩溃处理流程执行完毕。

复位模块14，用于若判断模块12判定崩溃处理流程未正确执行，则触发看门狗对系统进行复位，使崩溃处理流程终止执行。

可选的，如图6所示，判断模块12包括：

计时单元121，用于在崩溃处理模块开始执行崩溃处理流程时，读取系统的时钟源进行计时；

判断单元122，用于当计时单元121记录的时间达到预设时间后判断崩溃处理流程是否仍在执行；预设时间为预先通过测试得到的预期时间；若崩溃处理流程执行完毕，则判定崩溃处理流程正确执行；若崩溃处理流程仍在执行，则判定崩溃处理流程未正确执行。

可选的，如图7所示，判断模块12包括：

指令计数单元123，用于当开始执行崩溃处理流程的代码中的指令时，通过性能监控单元PMU记录执行指令的条数，其中，每执行一条指令，性能监控单元PMU中的计数寄存器的值递增一次；

判断单元124，用于判断计数寄存器的值递增的次数是否大于预先通过测试得到的预期指令条数；若计数寄存器的值递增的次数小于或等于预先通过测试得到的预期指令条数，则判定崩溃处理流程正确执行；若计数寄存器的值递增的次数大于预先通过测试得到的预期指令条数，则判定崩溃流程未正确执行。

可选的，判断模块12具体用于：

当崩溃处理模块11执行崩溃处理流程的代码至崩溃处理流程的代码中的预设代码时，判断系统中的预设变量的值是否小于第一预设阈值；其中，每当系统在崩溃处理流程中执行一次喂狗操作，则将预设变量的值进行一次增加调整；若预设变量的值小于第一预设阈值，则判定崩溃处理流程正确执行；若预设变量的值大于或等于第一预设阈值，则判定崩溃处理流程未正确执行。

可选的，判断模块12具体用于：

当崩溃处理模块11执行崩溃处理流程的代码至崩溃处理流程的代码中的预设代码时，判断系统中的预设变量的值是否大于第二预设阈值；其中，每当系统在崩溃处理流程中执行一次喂狗操作，则将预设变量的值进行一次减小调整；若预设变量的值大于第二预设阈值，则判定崩溃处理流程正确执行；若预设变量的值小于或等于第二预设阈值，则判定崩溃处理流程未正确执行。

可选的，如图8所示，该装置10还包括：

代码注入模块15，用于在系统初始化时根据系统的代码中的注入点利用动态注入技术将预设代码注入到系统的代码中的，其中，注入点是在系统初始化时读取配置信息获取的，配置信息包括：设备树中增加的节点、或命令行参数。

本实施例用于实现上述方法实施例，本实施例中各个单元的工作流程和工作原理参见上述方法实施例中的描述，在此不再赘述。

本发明实施例提供的一种用于处理系统崩溃的装置，当系统崩溃后，系统开始执行崩溃处理流程；在崩溃处理流程执行的过程中，根据预设策略判断崩溃处理流程是否正确执行；若崩溃处理流程正确执行，则对看门狗进行喂狗操作，使崩溃处理流程执行完毕；若崩溃处理流程未正确执行，则触发看门狗对系统进行复位，使崩溃处理流程终止执行。通过本发明提供的技术方案，当崩溃处理流程正确执行时可以使其执行完毕，当系统崩溃处理流程未正确执行时触发看门狗复位系统避免影响系统的可靠性

本发明的实施例提供的另一种处理系统崩溃的装置20，如图9所示，该装置20包括：总线24；以及连接到总线24的处理器21、存储器22和接口23，其中该接口23用于通信；该存储器22用于存储计算机代码，处理器21用于执行该计算机代码用于：

当系统崩溃后，系统开始执行崩溃处理流程；

在崩溃处理流程执行的过程中，根据预设策略判断崩溃处理流程是否正确执行；

若崩溃处理流程正确执行，则对看门狗进行喂狗操作，使崩溃处理流程执行完毕；

若崩溃处理流程未正确执行，则触发看门狗对系统进行复位，使崩溃处理流程终止执行。

可选的，处理器21执行该计算机代码用于根据预设策略判断崩溃处理流程是否正确执行，具体用于：

在崩溃处理流程开始执行时，读取系统的时钟源进行计时，经过预设时间后判断崩溃处理流程是否仍在执行；预设时间为预先通过测试得到的预期时间；

若崩溃处理流程执行完毕，则判定崩溃处理流程正确执行；

若崩溃处理流程仍在执行，则判定崩溃处理流程未正确执行。

可选的，处理器21执行该计算机代码用于根据预设策略判断崩溃处理流程是否正确执行，具体用于：

当开始执行崩溃处理流程的代码中的指令时，通过性能监控单元PMU记录执行指令的条数，其中，每执行一条指令，性能监控单元PMU中的计数寄存器的值递增一次；判断计数寄存器的值递增的次数是否大于预先通过测试得到的预期指令条数；

若计数寄存器的值递增的次数小于或等于预先通过测试得到的预期指令条数，则判定崩溃处理流程正确执行；

若计数寄存器的值递增的次数大于预先通过测试得到的预期指令条数，则判定崩溃流程未正确执行。

可选的，处理器21执行该计算机代码用于根据预设策略判断崩溃处理流程是否正确执行，具体用于：

当执行到崩溃处理流程的代码中的预设代码时，判断系统中的预设变量的值是否小于第一预设阈值；其中，每当系统在崩溃处理流程中执行一次喂狗操作，则将预设变量的值进行一次增加调整；

若预设变量的值小于第一预设阈值，则判定崩溃处理流程正确执行；

若预设变量的值大于或等于第一预设阈值，则判定崩溃处理流程未正确执行。

可选的，处理器21执行该计算机代码用于根据预设策略判断崩溃处理流程是否正确执行，具体用于：

当执行到崩溃处理流程的代码中的预设代码时，判断系统中的预设变量的值是否大于第二预设阈值；其中，每当系统在崩溃处理流程中执行一次喂狗操作，则将预设变量的值进行一次减小调整；

若预设变量的值大于第二预设阈值，则判定崩溃处理流程正确执行；

若预设变量的值小于或等于第二预设阈值，则判定崩溃处理流程未正确执行。

可选的，预设代码由用户在编写系统的代码时直接插入到系统的代码中；或者

预设代码是在系统初始化时根据系统的代码中的注入点利用动态注入技术注入到系统的代码中的，注入点是在系统初始化时读取配置信息获取的，配置信息包括：设备树中增加的节点、或命令行参数。

本发明实施例提供的另一种处理系统崩溃的装置，当系统崩溃后，系统开始执行崩溃处理流程；在崩溃处理流程执行的过程中，根据预设策略判断崩溃处理流程是否正确执行；若崩溃处理流程正确执行，则对看门狗进行喂狗操作，使崩溃处理流程执行完毕；若崩溃处理流程未正确执行，则触发看门狗对系统进行复位，使崩溃处理流程终止执行。通过本发明提供的技术方案，当崩溃处理流程正确执行时可以使其执行完毕，当系统崩溃处理流程未正确执行时触发看门狗复位系统避免影响系统的可靠性

本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。

Claims (12)

1.一种处理系统崩溃的方法，其特征在于，包括：

当系统崩溃后，所述系统开始执行崩溃处理流程；

在所述崩溃处理流程执行的过程中，根据预设策略判断所述崩溃处理流程是否正确执行；

若所述崩溃处理流程正确执行，则对看门狗进行喂狗操作，使所述崩溃处理流程执行完毕；

若所述崩溃处理流程未正确执行，则触发所述看门狗对所述系统进行复位，使所述崩溃处理流程终止执行。

2.根据权利要求1所述的方法，其特征在于，所述根据预设策略判断所述崩溃处理流程是否正确执行包括：

在所述崩溃处理流程开始执行时，读取所述系统的时钟源进行计时，经过预设时间后判断所述崩溃处理流程是否仍在执行；所述预设时间为预先通过测试得到的预期时间；

若所述崩溃处理流程执行完毕，则判定所述崩溃处理流程正确执行；

若所述崩溃处理流程仍在执行，则判定所述崩溃处理流程未正确执行。

3.根据权利要求1所述的方法，其特征在于，所述根据预设策略判断所述崩溃处理流程是否正确执行包括：

当开始执行所述崩溃处理流程的代码中的指令时，通过性能监控单元PMU记录执行所述指令的条数，其中，每执行一条所述指令，所述性能监控单元PMU中的计数寄存器的值递增一次；判断所述计数寄存器的值递增的次数是否大于预先通过测试得到的预期指令条数；

若所述计数寄存器的值递增的次数小于或等于所述预先通过测试得到的预期指令条数，则判定所述崩溃处理流程正确执行；

若所述计数寄存器的值递增的次数大于所述预先通过测试得到的预期指令条数，则判定所述崩溃流程未正确执行。

4.根据权利要求1所述的方法，其特征在于，所述根据预设策略判断所述崩溃处理流程是否正确执行包括：

当执行到所述崩溃处理流程的代码中的预设代码时，判断所述系统中的预设变量的值是否小于第一预设阈值；其中，每当所述系统在所述崩溃处理流程中执行一次喂狗操作，则将预设变量的值进行一次增加调整；

若所述预设变量的值小于所述第一预设阈值，则判定所述崩溃处理流程正确执行；

若所述预设变量的值大于或等于所述第一预设阈值，则判定所述崩溃处理流程未正确执行。

5.根据权利要求1所述的方法，其特征在于，所述根据预设策略判断所述崩溃处理流程是否正确执行包括：

当执行到所述崩溃处理流程的代码中的预设代码时，判断所述系统中的预设变量的值是否大于第二预设阈值；其中，每当所述系统在所述崩溃处理流程中执行一次喂狗操作，则将预设变量的值进行一次减小调整；

若所述预设变量的值大于所述第二预设阈值，则判定所述崩溃处理流程正确执行；

若所述预设变量的值小于或等于所述第二预设阈值，则判定所述崩溃处理流程未正确执行。

6.根据权利要求4或5所述的方法，其特征在于，所述预设代码由用户在编写所述系统的代码时直接插入到所述系统的代码中；或者

所述预设代码是在所述系统初始化时根据所述系统的代码中的注入点利用动态注入技术注入到所述系统的代码中的，所述注入点是在所述系统初始化时读取配置信息获取的，所述配置信息包括：设备树中增加的节点、或命令行参数。

7.一种用于处理系统崩溃的装置，其特征在于，包括：

崩溃处理模块，用于当系统崩溃后，开始执行崩溃处理流程；

判断模块，用于在所述崩溃处理模块执行所述崩溃处理流程的过程中，根据预设策略判断所述崩溃处理流程是否正确执行；

喂狗模块，用于若所述判断模块判定所述崩溃处理流程正确执行，对看门狗进行喂狗操作，使所述崩溃处理流程执行完毕；

复位模块，用于若所述判断模块判定所述崩溃处理流程未正确执行，则触发所述看门狗对所述系统进行复位，使所述崩溃处理流程终止执行。

8.根据权利要求7所述的装置，其特征在于，所述判断模块包括：

计时单元，用于在所述崩溃处理模块开始执行所述崩溃处理流程时，读取所述系统的时钟源进行计时；

判断单元，用于当所述计时单元记录的时间达到预设时间后判断所述崩溃处理流程是否仍在执行；所述预设时间为预先通过测试得到的预期时间；若所述崩溃处理流程执行完毕，则判定所述崩溃处理流程正确执行；若所述崩溃处理流程仍在执行，则判定所述崩溃处理流程未正确执行。

9.根据权利要求7所述的装置，其特征在于，所述判断模块包括：

指令计数单元，用于当开始执行所述崩溃处理流程的代码中的指令时，通过性能监控单元PMU记录执行所述指令的条数，其中，每执行一条所述指令，所述性能监控单元PMU中的计数寄存器的值递增一次；

判断单元，用于判断所述计数寄存器的值递增的次数是否大于预先通过测试得到的预期指令条数；若所述计数寄存器的值递增的次数小于或等于所述预先通过测试得到的预期指令条数，则判定所述崩溃处理流程正确执行；若所述计数寄存器的值递增的次数大于所述预先通过测试得到的预期指令条数，则判定所述崩溃流程未正确执行。

10.根据权利要求7所述的装置，其特征在于，所述判断模块具体用于：

当所述崩溃处理模块执行所述崩溃处理流程的代码至所述崩溃处理流程的代码中的预设代码时，判断所述系统中的预设变量的值是否小于第一预设阈值；其中，每当所述系统在所述崩溃处理流程中执行一次喂狗操作，则将预设变量的值进行一次增加调整；若所述预设变量的值小于所述第一预设阈值，则判定所述崩溃处理流程正确执行；若所述预设变量的值大于或等于所述第一预设阈值，则判定所述崩溃处理流程未正确执行。

11.根据权利要求7所述的装置，其特征在于，所述判断模块具体用于：

当所述崩溃处理模块执行所述崩溃处理流程的代码至所述崩溃处理流程的代码中的预设代码时，判断所述系统中的预设变量的值是否大于第二预设阈值；其中，每当所述系统在所述崩溃处理流程中执行一次喂狗操作，则将预设变量的值进行一次减小调整；若所述预设变量的值大于所述第二预设阈值，则判定所述崩溃处理流程正确执行；若所述预设变量的值小于或等于所述第二预设阈值，则判定所述崩溃处理流程未正确执行。

12.根据权利要求10或11所述的装置，其特征在于，所述装置还包括：

代码注入模块，用于在所述系统初始化时根据所述系统的代码中的注入点利用动态注入技术将所述预设代码注入到所述系统的代码中的，其中，所述注入点是在所述系统初始化时读取配置信息获取的，所述配置信息包括：设备树中增加的节点、或命令行参数。4 -->