CN103116532B - 从嵌入式软件系统中的堆栈损坏故障中恢复 - Google Patents

从嵌入式软件系统中的堆栈损坏故障中恢复 Download PDF

Info

Publication number
CN103116532B
CN103116532B CN201210462807.8A CN201210462807A CN103116532B CN 103116532 B CN103116532 B CN 103116532B CN 201210462807 A CN201210462807 A CN 201210462807A CN 103116532 B CN103116532 B CN 103116532B
Authority
CN
China
Prior art keywords
stack
task
memory
fault
overflow
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201210462807.8A
Other languages
English (en)
Other versions
CN103116532A (zh
Inventor
D.达斯
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
GM Global Technology Operations LLC
Original Assignee
GM Global Technology Operations LLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by GM Global Technology Operations LLC filed Critical GM Global Technology Operations LLC
Publication of CN103116532A publication Critical patent/CN103116532A/zh
Application granted granted Critical
Publication of CN103116532B publication Critical patent/CN103116532B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1479—Generic software techniques for error detection or fault masking
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1415—Saving, restoring, recovering or retrying at system level
    • G06F11/1438—Restarting or rejuvenating

Abstract

本发明涉及从嵌入式软件系统中的堆栈损坏故障中恢复，具体地，一种用于从堆栈上溢或堆栈下溢故障中恢复而不重新启动软件或硬件的方法和系统。在应用程序中的每个任务切换运行时，内存堆栈的一部分被拷贝到备用位置，使得堆栈的一部分在它随后在下一个任务的执行期间被堆栈上溢或堆栈下溢故障损坏时可被还原。状态变量数据类似地被拷贝到备用位置，使得它在下一个任务经历故障时可用来还原或估计该任务的输出。公开了用于选择对哪类状态变量数据以及内存堆栈的哪部分进行拷贝以备用的技术、以及用于检测堆栈上溢或堆栈下溢故障和在这种故障情况下还原状态变量和内存数据的技术。

Description

从嵌入式软件系统中的堆栈损坏故障中恢复
技术领域
本发明大体涉及软件故障恢复，并且更具体地，涉及一种用于从软件系统中的堆栈上溢和堆栈下溢故障中恢复的方法，该方法还原已损坏的内存区域、终止有故障的或已损坏的任务，以及估计该有故障的或已损坏的任务的输出和下一个状态。
背景技术
现代车辆以控制车辆性能的许多方面的自动系统为特征。这些系统使用变得日益精致且复杂的软件，且一些车辆包含包括数以百万的代码行数的系统。考虑到软件的复杂性，汽车制造商将车辆带入市场的短时间，以及车辆可被操作的状况的宽范围，该软件必定经历临时故障。
常见类型故障是堆栈上溢或堆栈下溢（统称，“堆栈上溢/下溢”或“堆栈损坏”）故障。在堆栈上溢/下溢故障中，程序试图将数据写入到内存堆栈的在规定的范围之外的一部分——要么在堆栈的起点上方（下溢），要么超过堆栈的最大范围（上溢）。堆栈上溢/下溢故障通常导致一些系统数据和/或堆栈内存的一些部分的损坏。虽然熟知用于堆栈上溢/下溢故障的检测技术，但是恢复技术不令人满意。在典型的软件系统中，对堆栈上溢/下溢故障的响应是要么重新启动所有的软件程序要么重新启动处理器硬件本身。因为许多嵌入式汽车系统实时运行，因此它们不能承受硬件或软件重新启动所花费的相对长时间的不工作。
存在对如下堆栈上溢/下溢故障恢复技术的需要：该技术不需要硬件或软件重新启动，但其在内存和处理器使用方面是足够有效的从而在高度资源受限的汽车环境中是可行的。
发明内容
根据本发明的教义，公开了一种用于从堆栈上溢/下溢故障中恢复而不重新启动软件或硬件的方法和系统。在应用程序中的每个任务切换运行时，内存堆栈的一部分被拷贝到备用位置，使得堆栈的一部分在它随后在下一个任务的执行期间被堆栈上溢或堆栈下溢故障损坏时可被还原。状态变量数据类似地被拷贝到备用位置，使得它在下一个任务经历故障时可用来还原或估计该任务的输出。公开了用于选择对哪类状态变量数据以及内存堆栈的哪部分进行拷贝以备用的技术、以及用于检测堆栈上溢/堆栈下溢故障和在这种故障情况下还原状态变量和内存数据的技术。
本发明还提供如下方案：
1.一种用于从在处理器上运行的软件应用中的堆栈上溢或堆栈下溢故障中恢复的方法，所述方法包括：
配置物理内存空间以包括堆栈内存和备用内存位置；
在应用程序中的任务切换时，将所述堆栈内存的一部分以及一组状态变量拷贝到所述备用内存位置；
确定堆栈上溢或堆栈下溢故障是否在前一个任务的执行期间发生；
如果所述堆栈上溢或堆栈下溢故障在所述前一个任务的执行期间发生，则还原对于所述前一个任务的已保存的一组状态变量；
如果所述堆栈上溢或堆栈下溢故障在所述前一个任务的执行期间发生，则终止所述前一个任务；
如果所述堆栈上溢或堆栈下溢故障在所述前一个任务的执行期间发生，则还原所述堆栈内存的已保存部分；以及
开始下一个任务。
2.根据方案1所述的方法，其特征在于，将所述堆栈内存的一部分拷贝到所述备用内存位置包括：将在用于所述下一个任务的堆栈警告器上方的堆栈内存段和在用于所述下一个任务的堆栈警告器下方的堆栈内存段拷贝到所述备用内存位置。
3.根据方案1所述的方法，其特征在于，将一组状态变量拷贝到所述备用内存位置包括：将用于所述下一个任务的状态变量拷贝到所述备用内存位置。
4.根据方案1所述的方法，其特征在于，确定在前一个任务的执行期间是否发生堆栈上溢或堆栈下溢故障包括：检查对于所述前一个任务的警告器值。
5.根据方案1所述的方法，其特征在于，还原对于所述前一个任务的已保存的一组状态变量包括：针对所述前一个任务使用估计算法来估计所述已保存的一组变量的改进值。
6.根据方案1所述的方法，其特征在于，还原堆栈内存的已保存部分包括：确定来自所述前一个任务的执行的堆栈上溢或堆栈下溢的量是否超过堆栈内存的已保存部分的大小。
7.根据方案6所述的方法，其特征在于，还原堆栈内存的已保存部分包括：如果来自所述前一个任务的执行的堆栈上溢的量超过所述堆栈内存的已保存部分的大小，则利用所述堆栈内存中的较低的内存地址递归地估计任务的输出和状态。
8.根据方案7所述的方法，其特征在于，如果来自所述前一个任务的执行的堆栈上溢的量超过堆栈内存的已保存部分的大小，则堆栈内存的已保存部分的大小被增加用于所述软件应用程序的未来执行。
9.根据方案6所述的方法，其特征在于，还原堆栈内存的已保存部分包括：如果来自所述前一个任务的执行的堆栈下溢的量超过所述堆栈内存的已保存部分的大小，则利用所述堆栈内存中的较高的内存地址递归地估计任务的输出和状态。
10.根据方案1所述的方法，其特征在于，还包括：如果所述堆栈上溢或堆栈下溢故障在所述前一个任务的执行期间发生，则存储所述前一个任务的参数数据。
11.根据方案10所述的方法，其特征在于，所述参数数据包括用于所述前一个任务的识别编号、用于所述前一个任务的输入数据、以及用于所述前一个任务的状态变量。
12.一种用于从在车辆中的微控制器上运行的软件应用中的堆栈上溢或堆栈下溢故障中恢复的方法，所述方法包括：
在应用程序中的任务切换时，将堆栈内存的一部分以及用于下一个任务的一组状态变量拷贝到备用内存位置，其中所述堆栈内存和所述备用内存位置是物理内存空间的一部分；
确定堆栈上溢或堆栈下溢故障是否在前一个任务的执行期间发生；
如果所述堆栈上溢或堆栈下溢故障在所述前一个任务的执行期间发生，则存储所述前一个任务的参数数据，其中所述参数数据包括用于所述前一个任务的识别编号、用于所述前一个任务的输入数据、以及用于所述前一个任务的状态变量；
如果所述堆栈上溢或堆栈下溢故障在所述前一个任务的执行期间发生，则还原对于所述前一个任务的已保存的一组状态变量；
如果所述堆栈上溢或堆栈下溢故障在所述前一个任务的执行期间发生，则终止所述前一个任务；
如果所述堆栈上溢或堆栈下溢故障在所述前一个任务的执行期间发生，则还原所述堆栈内存的已保存部分；和
开始下一个任务。
13.根据方案12所述的方法，其特征在于，确定在前一个任务的执行期间是否发生堆栈上溢或堆栈下溢故障包括：检查对于所述前一个任务的警告器值。
14.根据方案12所述的方法，其特征在于，还原对于所述前一个任务的已保存的一组状态变量包括：针对所述前一个任务使用估计算法来估计所述已保存的一组变量的改进值。
15.一种堆栈上溢或堆栈下溢故障恢复系统，所述系统包括：
用于执行多个任务的应用程序；
任务切换检查点模块，其在所述应用程序中的任务切换时，创建状态数据和内存数据的备用副本；
用于存储状态数据和内存数据的备用副本的数据备用模块；
用于检测堆栈上溢或堆栈下溢情况的故障检测模块；
用于识别已损坏的状态数据和已损坏的内存区域的数据损坏识别模块；
用于使用内存数据的备用副本来修复所述已损坏的内存区域的内存还原模块；
用于使用状态数据的备用副本来修复所述已损坏的状态数据的状态数据还原模块；以及
被配置成运行所述应用程序、所述任务切换检查点模块、所述数据备用模块、所述故障检测模块、所述数据损坏识别模块、所述内存还原模块、以及所述状态数据还原模块的处理器。
16.根据方案15所述的系统，其特征在于，在前一个任务已经完成免于故障执行时，所述任务切换检查点模块创建状态数据和内存数据的备用副本。
17.根据方案15所述的系统，其特征在于，所述故障检测模块使用一个或多个警告器值来检测所述堆栈上溢或堆栈下溢情况。
18.根据方案15所述的系统，其特征在于，在所述堆栈上溢或堆栈下溢情况期间，所述数据备用模块将状态数据和内存数据的备用副本存储在不能被盖写的内存堆栈位置。
19.根据方案15所述的系统，其特征在于，所述状态数据还原模块通过使用状态数据的备用副本作为输入而使用估计算法来估计对于所述已损坏的状态数据的新值。
20.根据方案15所述的系统，其特征在于，所述堆栈上溢或堆栈下溢故障恢复系统是汽车中的控制系统的一部分。
本发明的另外的特征将从结合附图所作出的下列描述和所附权利要求变得明显。
附图说明
图1是能够在不重新启动软件或硬件的情况下从堆栈损坏中恢复的系统的框图；
图2是内存堆栈的图示，示出了用于执行循环中的三个任务的堆栈的一部分；
图2A是图2的内存堆栈的图示，示出了在任务切换时的免于故障行为；
图2B是图2的内存堆栈的图示，示出了在任务切换时从堆栈上溢故障恢复；
图3是用于在不重新启动软件或硬件的情况下从堆栈上溢/下溢故障中恢复的方法的流程图；并且
图4是用于在上溢量超过可恢复的内存数据量的情况下从堆栈上溢/下溢故障中恢复的方法的流程图。
具体实施方式
对涉及从嵌入软件系统中的堆栈上溢/下溢故障中恢复的本发明的实施例的下列讨论，本质上仅仅是示例性的，并且决不旨在限制本发明或其应用或使用。特别地，下列讨论中的许多以汽车实时控制系统为中心，但是所公开的方法和系统同样地可应用于任何其它类型的会从堆栈损坏恢复受益的软件系统。
在软件系统中，当程序写到在预期数据结构之外的程序的调用堆栈上的内存地址时，堆栈上溢或下溢发生，该预期的数据结构通常是固定长度缓冲区。当（来自函数帧、中断帧或陷入（trap）帧的）太多数据被推到堆栈上时，堆栈上溢发生。当存在本地缓冲区的上溢时，堆栈下溢发生。堆栈上溢和下溢可由软件缺陷或由黑客发起的恶意攻击而引起。在任一情况下，堆栈上溢和下溢几乎总是导致堆栈上相邻数据的损坏，并且如果未被检测到则将常常导致程序损坏或不正确地运行。因此，在它们导致进一步的问题之前，存在检测堆栈损坏和对堆栈损坏定址的强烈动机。
在程序执行期间检查堆栈上溢和下溢是常用软件设计技术。用于检测堆栈上溢的一种方法是通过使用堆栈警告器。堆栈警告器，如此被命名是因为它们操作为在煤矿中的警告器（金丝雀canary）以提供问题的早期指示，被用来在进一步的有故障的代码执行会发生之前检测堆栈损坏。该方法通过将在程序开始时随机挑选的已知的数据值放置在恰在堆栈返回指针之前的内存中而起作用。通过限定，堆栈上溢/下溢是指数据已经被写在规定的地址范围之外，因此如果堆栈损坏发生，则警告器值将被盖写。对警告器值进行核查以确保它在例行程序使用在堆栈上的返回指针之前尚未改变。如果警告器具有不同于预期的值，则堆栈下溢可能已经发生。类似的技术可被用来检测堆栈上溢。堆栈警告器可在如上所述的函数调用返回时或在诸如任务切换的其它欠频繁的事件时被核查。
当检测到堆栈上溢或下溢时，通过检查警告器值或通过其它手段，大多数程序通常报告上溢/下溢情况，然后终止所有应用程序和/或重新启动处理器。然而，许多嵌入式汽车软件系统实时运行，并且无法承受持续执行软件程序或处理器的重新启动所花费的时间段的不工作。这样的系统将受益于如下方法：该方法可检测大多数堆栈上溢和下溢并且从堆栈上溢和下溢中恢复而不必重新启动程序或处理器。
图1是能够在不重新启动软件或硬件的情况下从堆栈上溢/下溢中恢复的系统10的框图。块12是连同系统10的所有的其它元件在处理器32上运行的应用程序。处理器32可以是用于嵌入式控制系统应用的微控制器，或更一般目的的微处理器或电子控制单元。每当任务在块12处的应用程序中完成时，控制被转移至块14，其中系统状态数据和内存数据被捕获并且被存储在数据存储区16中。数据存储区16沿用于任务的堆栈的堆栈上溢和堆栈下溢两个方向存储某些状态变量的检查点，并且存储系统内存的某些部分的备用副本，如将在下文详细地讨论。在块14处的状态数据捕获可不仅在两个任务的执行之间、而且也在任务和中断服务例行程序之间、或在中断服务例行程序和任务之间被调用。
在菱形18处，通过检查警告器值或通过另一适当的方法来检查堆栈上溢或堆栈下溢情况。如果在菱形18处没有检测到堆栈上溢或下溢，则控制返回到在块12处的程序，并且该程序继续运行。如果在菱形18处检测到堆栈上溢或下溢，则在块20处有故障的任务和已损坏的内存区域被识别。有故障的任务被认为是在控制被转移至块14之前执行的任务。已损坏的内存区域取决于引起堆栈上溢或下溢的任务，因为已损坏的区域是与在堆栈增长（stackgrowth）的方向上上溢或经过堆栈起点下溢的堆栈相邻的区域，如将在稍后的图中所示。一旦已损坏的内存区域在块20处被识别，则在对有故障的任务的调用之前，通过用被拷贝到数据存储区16中的安全位置的固定大小的内存块来盖写该已损坏的内存区域，该已损坏的内存区域在块22处可被还原。块24是包含已还原的内存块的经修复的软件系统。
在块22处在已损坏的内存区域的恢复期间，如果确定重要的调用堆栈数据被盖写用于引起堆栈损坏的任务，则在块26处有故障的任务被终止并且其输出以及下一个状态被还原或估计。下一个应用输出和状态可在调用有故障的任务之前根据应用状态来估计，该有故障的任务可从数据存储区16获得。块28包含已还原的或估计的输出以及用于修复的步骤的下一个状态。框30内的操作在块12处的应用程序中的每个任务切换处进行，并且将在下文更详细地被讨论。
代替在任务切换时，系统10还可被用来在函数调用时检测堆栈上溢或下溢以及从堆栈上溢或下溢中恢复。在这种情况下，在函数调用时，控制将被转移至块14。系统10的剩余部分与以上描述相比将不变化；状态数据备用将在函数执行之前被捕获在数据存储区16中，堆栈上溢/下溢情况将在函数执行之后在菱形18被检查，并且从堆栈上溢/下溢情况的恢复将在块20-28处被实施。
图2是示出了用于在程序的执行循环中的三个任务的元素的内存空间36的图示。堆栈段40包含用于任务0的堆栈数据，并且由已被占用的任务0堆栈42、未被占用的任务0堆栈44、以及任务0警告器46组成。如此处所图示，堆栈段40是从“从下到上”写入的固定大小的空间，当前存储在已被占用的任务0堆栈42中的堆栈数据消耗该空间的一些，任务0警告器46消耗在段40的顶部处的少量空间，并且堆栈段40中的空间的剩余部分是未被占用的任务0堆栈44。堆栈段40的结构被复制用于任务1堆栈段50，其由已被占用的任务1堆栈52、未被占用的任务1堆栈54、以及任务1警告器56组成。结构还被复制用于任务2堆栈段60，其由已被占用的任务2堆栈62、未被占用的任务2堆栈64、以及任务2警告器66组成。内存空间36还包括由O/S堆栈72和O/S警告器74组成的操作系统（O/S）堆栈段70。
备用内存空间80是随机存取存储区，该随机存取存储区用来存储来自空间36中较高处的内存的备用副本，以及还用来存储状态变量检查点数据。备用内存空间80代表图1中所示的数据存储区16的存储位置。将在下文对图2A和图2B的讨论中进一步对备用内存空间80的运行作出解释。注意，备用内存空间80也可能被放置在全局内存空间90中的空间36的顶部处。
全局内存空间90由在块12处的应用程序使用以存储诸如状态变量的关键变量，这些关键变量可能需要由执行循环中的任何任务访问。由于全局内存空间90的运行涉及此处所公开的堆栈上溢/下溢恢复方法，所以将在下文对图2A和图2B的讨论中进一步对全局内存空间90的运行作出解释。
图2A是图示出在任务2和任务0之间的任务切换时的免于故障行为的内存空间36的图示。图2A图示出为了提供保护免受堆栈上溢故障而采取的先发制人的措施。可采取（为清楚起见而未示出的）类似的措施（从任务的堆栈下方捕获内存）来保护免受堆栈下溢故障。因为任务0是下一个将被执行的任务，所以期望在任务0堆栈段40上方建立内存的一部分的备用副本，使得万一任务0在执行时引起堆栈上溢，则恢复将是可能的。因此，在执行任务0之前，包括来自已被占用的任务1堆栈52的内存的M个字节的段58被拷贝到备用内存空间80中的备用内存段84。在一个实施例中，段58和84的大小M在程序执行之前被确定，并且针对全部内存备用和还原操作保持固定。在另一个实施例中，大小M在初始值建立，并且在程序执行期间，如果必要，则该M可增大，如将在下文进一步讨论的。在执行任务0之前，还期望创建任务0状态变量的检查点副本，以防它们被需要用于稍后恢复。因此，代表先前由任务0计算的状态变量的任务0状态变量数据段92和94被拷贝到在备用内存空间80中的任务0状态存储位置82。
备用内存空间80被设计成带有单个备用内存段84，该备用内存段84被用来存储在紧上方的内存的一部分（用于上溢），无论何种任务即将开始。第二备用内存段（未示出）将被用来存储在紧下方的内存的一部分（用于下溢），无论何种任务即将开始。然而，备用内存空间80包括多个状态变量存储位置，每个任务一个位置，诸如任务0状态存储位置82。在该示例中，如果任务0的执行随后被发现引起堆栈上溢，则任务0状态存储位置82以及备用内存段84的内容可被用于稍后恢复。在开始执行任务0之前，进行检查以确定被执行的上一个任务（任务2）是否引起堆栈上溢。任务2警告器66被检查并且确定为具有预期值，意味着无堆栈上溢发生，因此控制可被返回到在块12处的应用程序用于任务0的执行。
图2B是图示出从在任务2和任务0之间的任务切换处的堆栈上溢故障恢复的内存空间36的图示。再一次，相同的构思可被用于堆栈下溢故障恢复，但是为了清楚仅在图2B中图示出上溢。在这种情况下，当任务2警告器66被检查时，确定已经被盖写，意味着堆栈上溢在任务2的执行期间已经发生。在传统的软件系统中，堆栈上溢将导致系统崩溃或必须使系统重新启动，如先前所讨论，其将引起实时系统的不能接受的停机时间。然而，使用此处公开的恢复方法，可避免系统崩溃或重新启动。
在图2B中，因为任务2警告器66被确定为损坏，所以任务0的执行不开始。相反地，来自备用内存空间80的数据必须被拷贝后到内存空间36中适当的位置。从堆栈上溢恢复的一个要素是重新填充（re-populate）来自前一个检查点的状态变量数据。由于已知任务2的执行有故障，所以来自任务2状态存储位置86的状态变量数据被拷贝回到全局内存空间90中的任务2状态变量数据段96。
另外，备用内存段84的内容必须被拷贝回内存空间36中适当的位置。在任务2的故障执行之前，备用内存段84将已经被填充有来自在任务2堆栈段60紧上方的堆栈位置的M个字节的内存，该堆栈位置是O/S堆栈72。因此，因为O/S堆栈72的部分可能在任务2执行期间的堆栈上溢中被盖写，所以备用内存段84必须被拷贝回到O/S堆栈72中的段76。随着状态变量数据和内存从备用内存空间80还原，继续执行任务0是可能的。
图3是用于通过使用上述内存和状态变量备用副本技术从堆栈上溢恢复而不重新启动软件或硬件的方法的流程图100。因为图3涉及堆栈下溢检测和恢复，所以下面接着对图3进行讨论。对流程图100的讨论包括对图2、图2A和图2B的内存空间36的元素的参考。在框102处，应用程序准备从任务Ti切换到任务Td。如先前所讨论，框102还可能代表从中断服务例行程序（ISR）到任务的切换，或从任务到ISR的切换。在框104处，用于任务Td的状态变量数据被存储在备用内存空间80的被指定用于任务Td状态数据的段中。另外，在框104处，来自任务Td的堆栈上方的M个字节的内存被拷贝到备用内存空间80的被指定用于内存副本的段，诸如备用内存段84。
在决策菱形106处，确定是否存在任务Ti的堆栈上溢。如果不存在任务Ti的堆栈上溢，则该过程继续到框108，在该框108中，任务Td开始。如果存在任务Ti的堆栈上溢，则该过程继续从决策菱形106到框110，在该框110中，任务Ti的状态数据被恢复。任务Ti的状态数据可通过直接从备用内存空间80中的指定位置拷贝到全局内存空间90中合适的位置而恢复，如先前所讨论。也可通过将估计算法Ei应用到任务Ti的存储在备用内存空间80中的状态数据来估计对于任务Ti的状态数据的改进值。对估计算法进一步讨论如下。可选地，任务Ti参数数据可被存储在框110处以在事实后辅助故障诊断，其中任务Ti参数数据包括：i（指示哪个任务经历了故障）的值；所有输入到任务Ti的值；以及任务Ti的状态变量数据。
最后，在离开框110之前，任务Ti被终止。此时，在任务Ti的堆栈上溢之后，任务Ti已经被终止并且任务Ti的状态数据已经被还原。然后，将内存数据从备用内存空间80还原到内存空间36的已经因堆栈上溢而受损的无论哪一部分是必需的。在决策菱形112处，确定来自任务Ti的堆栈上溢是否超过M个字节。这通过检查备用内存段84的最后字词是否与它将被还原到的位置中最后字词相同来完成。如果来自任务Ti的堆栈上溢不超过M个字节，则在框114处，备用内存段84可被拷贝到它将被还到的位置，然后任务Td可在框108处开始。
如果在决策菱形112处，确定来自任务Ti的堆栈上溢超过M个字节，则在框116处，作出从不可还原的堆栈上溢恢复的尝试。如果该尝试成功，则该过程继续到框108，在该框108中，任务Td开始。如果从不可还原堆栈上溢恢复的该尝试在框116处不成功，则该过程在终点118处停止，并且应用程序必须重新开始。从不可还原堆栈上溢过程恢复的细节在图4中示出并且在下文中讨论。
流程图100中所示的方法所需的输入包括任务列、一组下一状态估计算法、以及备用内存空间80的映射。对于应用程序中的多个任务k，任务列{T0,T1…,Tk-1}必须被以递减的堆栈起始地址的顺序设置。下一状态估计算法(E0,E1,…,Ek-1)必须被设置用于k个任务中的每一个，其中这些算法由应用程序的程序员事先创建，并且基于已知数据诸如来自前一个执行循环的状态变量值估计这些任务中的每一个的输出。其它所需的输入、备用内存空间80的映射必须包括备用内存段84的内存堆栈位置和k个任务中的每一个的状态存储位置。
图3中流程图100的方法可被用来检测除堆栈上溢之外的堆栈下溢故障以及从该堆栈下溢故障恢复。这可以两种方式中的一种来完成。第二整套步骤可被执行用于下溢（例如，紧接在上溢检查的成功完成之后），或下溢检查可被直接合并到流程图100的方法中（通过在决策菱形106处检查上溢或下溢，并且如果任一种被检测到，则相应地继续进行恢复）。
流程图100的方法还可被用来在函数调用返回时而不是在任务切换时检测堆栈上溢/下溢以及从堆栈上溢/下溢中恢复。在这种情况下，框102将代表函数调用返回而不是任务切换。流程图100的方法的剩余部分与以上描述相比将不变化；状态数据备用将在框104处被捕获，堆栈上溢/下溢情况将在决策菱形106处被检查，并且从堆栈上溢/下溢情况的恢复将在框110处及以下执行。缓冲区上溢检查侵害也可触发上述操作。
图4是用于在上溢或下溢量超过可恢复的内存数据量的情况下从堆栈上溢或下溢中恢复的方法的流程图120。流程图120–将首先在上溢故障的背景下被讨论——图示出在图3的讨论中被引入的在框116内发生了什么。如上所讨论的，在框116处，作出从故障恢复的尝试，在所述故障中，来自任务Ti的堆栈上溢超过M个字节。在这样的情形下，决策菱形112通向框116。在决策菱形122处，确定任务Ti的堆栈是否上溢超过上一个任务Tk-1的堆栈段。这可通过检查上一个任务Tk-1的警告器值来确定。如果任务Ti的堆栈上溢超过上一个任务Tk-1的堆栈段，则这是不可恢复的情形，并且该过程在终点118处停止，其中应用程序重新开始。
如果任务Ti的堆栈没有上溢超过上一个任务Tk-1的堆栈段，则该过程继续到框124，其中计数p被赋予值1。在框126处，任务Ti+p的下一个状态使用被应用到任务Ti+p的存储在备用内存空间80中的状态数据的估计算法Ei+p来估计。然后，任务Ti+p被终止，并且计数p增加1。在决策菱形128处，确定任务Ti的堆栈是否上溢超过任务Ti+p的堆栈段。如果否，则恢复完成，并且该过程继续到框108，在该框108中，任务Td开始，如先前所讨论。
如果在决策菱形128处，确定任务Ti的堆栈上溢超过任务Ti+p的堆栈段，则该过程环回到框126，在该框126中，下一个较大的任务数的状态使用其估计算法来估计，该任务终止，并且计数再一次增加。在框126和决策菱形128之间的循环继续，直到堆栈上溢的范围已经被确定为止，并且对于堆栈数据已经由堆栈上溢盖写的所有任务的下一个状态已经被估计。然后，该过程下降到框108，在该框108中，针对执行下一个而安排的任务Td开始。
先前提及的是，备用内存段84的大小M可被允许在程序执行期间增大。这可在如下流程图120中完成。每当流程图120的过程被执行时，M的值可增加到将被需要从刚刚遭遇的堆栈上溢（或下溢）恢复的内存量。也就是，如由计数p测量的堆栈上溢的任务的数量可被用来确定M的未来值。
以类似于先前所讨论的方式，流程图120的方法可被应用于下溢故障以及上溢故障。当被应用到堆栈下溢故障时，确定来自任务Ti的下溢量是否超过M个字节，并且如果是，则超过多少。该确定通过为隶属于前一个任务的堆栈递归地检查警告器值而作出，直到下溢的范围被识别为止。如果下溢扩展超过第一任务T1的堆栈起点，则这是不可恢复的情形，并且应用程序将重新开始。
原型实施方式已经表明，所公开的方法使得堆栈上溢/下溢故障恢复成为可能，而资源消耗开支是最小的。从堆栈上溢/下溢故障中恢复而不重新启动硬件或软件，对于嵌入式汽车系统或不能容忍停机时间中断的任何其它系统来说，会是非常有利的。
上面的讨论仅公开并描述了本发明的示例性实施例。根据这样的讨论以及根据附图和权利要求，本领域的技术人员将容易地意识到，在不脱离如所附权利要求中所限定的本发明的精神和范围的情况下，能够在其中作出各种改变、修改和变型。

Claims (20)

1.一种用于从在处理器上运行的软件应用中的堆栈上溢或堆栈下溢故障中恢复的方法，所述方法包括：
配置物理内存空间以包括堆栈内存和备用内存位置；
在应用程序中的任务切换时，将所述堆栈内存的一部分以及一组状态变量拷贝到所述备用内存位置；
确定堆栈上溢或堆栈下溢故障是否在前一个任务的执行期间发生；
如果所述堆栈上溢或堆栈下溢故障在所述前一个任务的执行期间发生，则还原对于所述前一个任务的已保存的一组状态变量；
如果所述堆栈上溢或堆栈下溢故障在所述前一个任务的执行期间发生，则终止所述前一个任务；
如果所述堆栈上溢或堆栈下溢故障在所述前一个任务的执行期间发生，则还原所述堆栈内存的已保存部分；以及
开始下一个任务。
2.根据权利要求1所述的方法，其特征在于，将所述堆栈内存的一部分拷贝到所述备用内存位置包括：将在用于所述下一个任务的堆栈警告器上方的堆栈内存段和在用于所述下一个任务的堆栈警告器下方的堆栈内存段拷贝到所述备用内存位置。
3.根据权利要求1所述的方法，其特征在于，将一组状态变量拷贝到所述备用内存位置包括：将用于所述下一个任务的状态变量拷贝到所述备用内存位置。
4.根据权利要求1所述的方法，其特征在于，确定在前一个任务的执行期间是否发生堆栈上溢或堆栈下溢故障包括：检查对于所述前一个任务的警告器值。
5.根据权利要求1所述的方法，其特征在于，还原对于所述前一个任务的已保存的一组状态变量包括：针对所述前一个任务使用估计算法来估计所述已保存的一组变量的改进值。
6.根据权利要求1所述的方法，其特征在于，还原堆栈内存的已保存部分包括：确定来自所述前一个任务的执行的堆栈上溢或堆栈下溢的量是否超过堆栈内存的已保存部分的大小。
7.根据权利要求6所述的方法，其特征在于，还原堆栈内存的已保存部分包括：如果来自所述前一个任务的执行的堆栈上溢的量超过所述堆栈内存的已保存部分的大小，则利用所述堆栈内存中的较低的内存地址递归地估计任务的输出和状态。
8.根据权利要求7所述的方法，其特征在于，如果来自所述前一个任务的执行的堆栈上溢的量超过堆栈内存的已保存部分的大小，则堆栈内存的已保存部分的大小被增加用于所述软件应用程序的未来执行。
9.根据权利要求6所述的方法，其特征在于，还原堆栈内存的已保存部分包括：如果来自所述前一个任务的执行的堆栈下溢的量超过所述堆栈内存的已保存部分的大小，则利用所述堆栈内存中的较高的内存地址递归地估计任务的输出和状态。
10.根据权利要求1所述的方法，其特征在于，还包括：如果所述堆栈上溢或堆栈下溢故障在所述前一个任务的执行期间发生，则存储所述前一个任务的参数数据。
11.根据权利要求10所述的方法，其特征在于，所述参数数据包括用于所述前一个任务的识别编号、用于所述前一个任务的输入数据、以及用于所述前一个任务的状态变量。
12.一种用于从在车辆中的微控制器上运行的软件应用中的堆栈上溢或堆栈下溢故障中恢复的方法，所述方法包括：
在应用程序中的任务切换时，将堆栈内存的一部分以及用于下一个任务的一组状态变量拷贝到备用内存位置，其中所述堆栈内存和所述备用内存位置是物理内存空间的一部分；
确定堆栈上溢或堆栈下溢故障是否在前一个任务的执行期间发生；
如果所述堆栈上溢或堆栈下溢故障在所述前一个任务的执行期间发生，则存储所述前一个任务的参数数据，其中所述参数数据包括用于所述前一个任务的识别编号、用于所述前一个任务的输入数据、以及用于所述前一个任务的状态变量；
如果所述堆栈上溢或堆栈下溢故障在所述前一个任务的执行期间发生，则还原对于所述前一个任务的已保存的一组状态变量；
如果所述堆栈上溢或堆栈下溢故障在所述前一个任务的执行期间发生，则终止所述前一个任务；
如果所述堆栈上溢或堆栈下溢故障在所述前一个任务的执行期间发生，则还原所述堆栈内存的已保存部分；和
开始下一个任务。
13.根据权利要求12所述的方法，其特征在于，确定在前一个任务的执行期间是否发生堆栈上溢或堆栈下溢故障包括：检查对于所述前一个任务的警告器值。
14.根据权利要求12所述的方法，其特征在于，还原对于所述前一个任务的已保存的一组状态变量包括：针对所述前一个任务使用估计算法来估计所述已保存的一组变量的改进值。
15.一种堆栈上溢或堆栈下溢故障恢复系统，所述系统包括：
用于执行多个任务的应用程序；
任务切换检查点模块，其在所述应用程序中的任务切换时，创建状态数据和内存数据的备用副本；
用于存储状态数据和内存数据的备用副本的数据备用模块；
用于检测堆栈上溢或堆栈下溢情况的故障检测模块；
在所述故障检测模块检测到堆栈上溢或堆栈下溢情况时用于识别已损坏的状态数据和已损坏的内存区域的数据损坏识别模块；
在所述故障检测模块检测到堆栈上溢或堆栈下溢情况时用于使用来自所述数据备用模块的内存数据的备用副本来修复所述已损坏的内存区域的内存还原模块；
在所述故障检测模块检测到堆栈上溢或堆栈下溢情况时用于使用来自所述数据备用模块的状态数据的备用副本来修复所述已损坏的状态数据的状态数据还原模块；以及
被配置成运行所述应用程序、所述任务切换检查点模块、所述数据备用模块、所述故障检测模块、所述数据损坏识别模块、所述内存还原模块、以及所述状态数据还原模块的处理器。
16.根据权利要求15所述的系统，其特征在于，在前一个任务已经完成免于故障执行时，所述任务切换检查点模块创建状态数据和内存数据的备用副本。
17.根据权利要求15所述的系统，其特征在于，所述故障检测模块使用一个或多个警告器值来检测所述堆栈上溢或堆栈下溢情况。
18.根据权利要求15所述的系统，其特征在于，在所述堆栈上溢或堆栈下溢情况期间，所述数据备用模块将状态数据和内存数据的备用副本存储在不能被盖写的内存堆栈位置。
19.根据权利要求15所述的系统，其特征在于，所述状态数据还原模块通过使用状态数据的备用副本作为输入而使用估计算法来估计对于所述已损坏的状态数据的新值。
20.根据权利要求15所述的系统，其特征在于，所述堆栈上溢或堆栈下溢故障恢复系统是汽车中的控制系统的一部分。
CN201210462807.8A 2011-11-16 2012-11-16 从嵌入式软件系统中的堆栈损坏故障中恢复 Active CN103116532B (zh)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US13/297822 2011-11-16
US13/297,822 US8677189B2 (en) 2011-11-16 2011-11-16 Recovering from stack corruption faults in embedded software systems
US13/297,822 2011-11-16

Publications (2)

Publication Number Publication Date
CN103116532A CN103116532A (zh) 2013-05-22
CN103116532B true CN103116532B (zh) 2016-01-20

Family

ID=48145296

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201210462807.8A Active CN103116532B (zh) 2011-11-16 2012-11-16 从嵌入式软件系统中的堆栈损坏故障中恢复

Country Status (3)

Country Link
US (1) US8677189B2 (zh)
CN (1) CN103116532B (zh)
DE (1) DE102012109614B4 (zh)

Families Citing this family (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101470162B1 (ko) * 2013-05-30 2014-12-05 현대자동차주식회사 메모리 스택 사이즈 모니터링 방법
CN105630479A (zh) * 2014-11-28 2016-06-01 中兴通讯股份有限公司 程序运行过程中的异常处理方法及装置
US11616719B2 (en) * 2015-10-23 2023-03-28 Netflix, Inc Techniques for determining client-side effects of server-side behavior using canary analysis
KR101714525B1 (ko) * 2015-11-27 2017-03-22 현대자동차주식회사 차량 해킹 방지 방법 및 그를 위한 장치 및 시스템
US9904485B2 (en) * 2016-03-31 2018-02-27 Intel Corporation Secure memory controller
CN107766128B (zh) * 2016-08-17 2021-01-29 华为技术有限公司 一种启动应用的方法及装置
US10067710B2 (en) * 2016-11-23 2018-09-04 Advanced Micro Devices, Inc. Detecting buffer overflows in general-purpose GPU applications
US10586038B2 (en) 2017-09-08 2020-03-10 Qualcomm Incorporated Secure stack overflow protection via a hardware write-once register
KR102022168B1 (ko) * 2017-12-15 2019-09-18 이방훈 하드웨어 태스크 스위칭을 이용한 은닉 태스크의 감지 방법 및 장치
US10613864B2 (en) * 2018-03-16 2020-04-07 Texas Instruments Incorporated Processor with hardware supported memory buffer overflow detection
US11126505B1 (en) * 2018-08-10 2021-09-21 Amazon Technologies, Inc. Past-state backup generator and interface for database systems
CN110895499A (zh) * 2018-09-13 2020-03-20 北京奇虎科技有限公司 程序溢出保护方法及装置
CN110532138A (zh) * 2019-09-16 2019-12-03 杭州和利时自动化有限公司 一种控制器故障恢复方法、装置、设备及可读存储介质
CN110597601A (zh) * 2019-09-16 2019-12-20 杭州和利时自动化有限公司 一种控制器任务切换方法、装置、设备及可读存储介质
JP7427474B2 (ja) * 2020-02-27 2024-02-05 三菱重工業株式会社 観測制御装置、観測システム、及び宇宙機、並びに観測制御方法、並びに観測制御プログラム
CN113849339B (zh) * 2020-06-28 2023-07-11 华为技术有限公司 恢复应用程序的运行状态的方法、装置及存储介质
CN112817715A (zh) * 2021-01-28 2021-05-18 展讯通信(天津)有限公司 任务切换方法、装置及设备
US11256561B1 (en) 2021-03-04 2022-02-22 Smart Information Flow Technologies, LLC Computer program crash handling

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1851648A (zh) * 2006-05-25 2006-10-25 浙江大学 一种嵌入式系统运行时堆栈溢出保护方法

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5668999A (en) * 1994-12-20 1997-09-16 Sun Microsystems, Inc. System and method for pre-verification of stack usage in bytecode program loops
US5644742A (en) * 1995-02-14 1997-07-01 Hal Computer Systems, Inc. Processor structure and method for a time-out checkpoint
AU9176698A (en) * 1997-09-25 1999-04-12 British Telecommunications Public Limited Company Memory allocation
US7380245B1 (en) * 1998-11-23 2008-05-27 Samsung Electronics Co., Ltd. Technique for detecting corruption associated with a stack in a storage device
US20020099932A1 (en) * 2001-01-25 2002-07-25 Muro Manuel R. Mirroring processor stack
US7272748B1 (en) * 2004-03-17 2007-09-18 Symantec Corporation Method and apparatus to detect and recover from a stack frame corruption
US7752427B2 (en) * 2005-12-09 2010-07-06 Atmel Corporation Stack underflow debug with sticky base
US7617383B2 (en) * 2006-02-16 2009-11-10 Vns Portfolio Llc Circular register arrays of a computer
US8079019B2 (en) 2007-11-21 2011-12-13 Replay Solutions, Inc. Advancing and rewinding a replayed program execution
US20080034169A1 (en) * 2006-08-07 2008-02-07 Barrett Trask Pseudo-FIFO memory configuration using dual FIFO memory stacks operated by atomic instructions
US7793149B2 (en) * 2007-02-20 2010-09-07 International Business Machines Corporation Kernel error recovery disablement and shared recovery routine footprint areas
JP4479743B2 (ja) * 2007-04-24 2010-06-09 株式会社デンソー ロールバック方法及び情報処理装置
US8539210B2 (en) * 2007-11-30 2013-09-17 Microchip Technology Incorporated Context switching with automatic saving of special function registers memory-mapped to all banks

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1851648A (zh) * 2006-05-25 2006-10-25 浙江大学 一种嵌入式系统运行时堆栈溢出保护方法

Also Published As

Publication number Publication date
DE102012109614B4 (de) 2023-05-17
US8677189B2 (en) 2014-03-18
CN103116532A (zh) 2013-05-22
DE102012109614A1 (de) 2013-05-16
US20130124917A1 (en) 2013-05-16

Similar Documents

Publication Publication Date Title
CN103116532B (zh) 从嵌入式软件系统中的堆栈损坏故障中恢复
US8255614B2 (en) Information processing device that accesses memory, processor and memory management method
TWI490876B (zh) 系統啟動引導處理方法及裝置
KR970066876A (ko) 계산기 시스템 및 그 소프트웨어 고장 회복 방법
CN103226499A (zh) 一种恢复内部存储器中的异常数据的方法及装置
CN101231604A (zh) 用于集群服务器数据的卷级恢复的设备、系统及方法
CN105589765A (zh) 一种实现程序备份的方法
CN100538644C (zh) 执行计算机程序的方法、计算设备
US20140032962A1 (en) System and Methods for Self-Healing From Operating System Faults in Kernel/Supervisory Mode
JP2009506445A (ja) 記憶装置構成およびその駆動方法
CN101174221A (zh) 以闪速存储器存储开机码的电子系统及开机方法
KR101548452B1 (ko) 비휘발성 메모리 기반의 전자 장치의 메타 데이터 복원 방법 및 장치
CN109086162B (zh) 一种内存诊断方法和装置
CN104699574B (zh) 一种建立处理器Cache检查点的方法、装置及系统
CN100511165C (zh) 执行计算机程序的方法、操作系统以及计算设备
US20100169572A1 (en) Data storage method, apparatus and system for interrupted write recovery
CN101546281A (zh) 提高嵌入式系统可靠性的方法和装置
US10592329B2 (en) Method and electronic device for continuing executing procedure being aborted from physical address where error occurs
CN102831032A (zh) 硬盘主引导记录的修复系统及方法
KR101545077B1 (ko) 비휘발성 메모리 기반의 전자 장치의 메타 데이터 복원 방법 및 장치
CN112328426A (zh) 系统uboot损坏检测及恢复方法
JP2000132462A (ja) プログラム自己修復方式
CN101464817B (zh) 数据恢复方法
JP7180319B2 (ja) 情報処理装置、及び情報処理装置のダンプ管理方法
JP5770557B2 (ja) 情報更生装置、メモリ制御システム、情報更生方法およびコンピュータプログラム

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C14 Grant of patent or utility model
GR01 Patent grant