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

摘要

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

说明书

技术领域

本发明大体涉及软件故障恢复，并且更具体地，涉及一种用于从软件系统中的堆栈上溢和堆栈下溢故障中恢复的方法，该方法还原已损坏的内存区域、终止有故障的或已损坏的任务，以及估计该有故障的或已损坏的任务的输出和下一个状态。

背景技术

现代车辆以控制车辆性能的许多方面的自动系统为特征。这些系统使用变得日益精致且复杂的软件，且一些车辆包含包括数以百万的代码行数的系统。考虑到软件的复杂性，汽车制造商将车辆带入市场的短时间，以及车辆可被操作的状况的宽范围，该软件必定经历临时故障。

常见类型故障是堆栈上溢或堆栈下溢（统称，“堆栈上溢/下溢”或“堆栈损坏”）故障。在堆栈上溢/下溢故障中，程序试图将数据写入到内存堆栈的在规定的范围之外的一部分——要么在堆栈的起点上方（下溢），要么超过堆栈的最大范围（上溢）。堆栈上溢/下溢故障通常导致一些系统数据和/或堆栈内存的一些部分的损坏。虽然熟知用于堆栈上溢/下溢故障的检测技术，但是恢复技术不令人满意。在典型的软件系统中，对堆栈上溢/下溢故障的响应是要么重新启动所有的软件程序要么重新启动处理器硬件本身。因为许多嵌入式汽车系统实时运行，因此它们不能承受硬件或软件重新启动所花费的相对长时间的不工作。

存在对如下堆栈上溢/下溢故障恢复技术的需要：该技术不需要硬件或软件重新启动，但其在内存和处理器使用方面是足够有效的从而在高度资源受限的汽车环境中是可行的。

发明内容

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

本发明还提供如下方案：

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之前执行的任务。已损坏的内存区域取决于引起堆栈上溢或下溢的任务，因为已损坏的区域是与在堆栈增长（stack growth）的方向上上溢或经过堆栈起点下溢的堆栈相邻的区域，如将在稍后的图中所示。一旦已损坏的内存区域在块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处，应用程序准备从任务T_i切换到任务T_d。如先前所讨论，框102还可能代表从中断服务例行程序（ISR）到任务的切换，或从任务到ISR的切换。在框104处，用于任务T_d的状态变量数据被存储在备用内存空间80的被指定用于任务T_d状态数据的段中。另外，在框104处，来自任务T_d的堆栈上方的M个字节的内存被拷贝到备用内存空间80的被指定用于内存副本的段，诸如备用内存段84。

在决策菱形106处，确定是否存在任务T_i的堆栈上溢。如果不存在任务T_i的堆栈上溢，则该过程继续到框108，在该框108中，任务T_d开始。如果存在任务T_i的堆栈上溢，则该过程继续从决策菱形106到框110，在该框110中，任务T_i的状态数据被恢复。任务T_i的状态数据可通过直接从备用内存空间80中的指定位置拷贝到全局内存空间90中合适的位置而恢复，如先前所讨论。也可通过将估计算法E_i应用到任务T_i的存储在备用内存空间80中的状态数据来估计对于任务T_i的状态数据的改进值。对估计算法进一步讨论如下。可选地，任务T_i参数数据可被存储在框110处以在事实后辅助故障诊断，其中任务T_i参数数据包括：i（指示哪个任务经历了故障）的值；所有输入到任务T_i的值；以及任务T_i的状态变量数据。

最后，在离开框110之前，任务T_i被终止。此时，在任务T_i的堆栈上溢之后，任务T_i已经被终止并且任务T_i的状态数据已经被还原。然后，将内存数据从备用内存空间80还原到内存空间36的已经因堆栈上溢而受损的无论哪一部分是必需的。在决策菱形112处，确定来自任务T_i的堆栈上溢是否超过M个字节。这通过检查备用内存段84的最后字词是否与它将被还原到的位置中最后字词相同来完成。如果来自任务T_i的堆栈上溢不超过M个字节，则在框114处，备用内存段84可被拷贝到它将被还到的位置，然后任务T_d可在框108处开始。

如果在决策菱形112处，确定来自任务T_i的堆栈上溢超过M个字节，则在框116处，作出从不可还原的堆栈上溢恢复的尝试。如果该尝试成功，则该过程继续到框108，在该框108中，任务T_d开始。如果从不可还原堆栈上溢恢复的该尝试在框116处不成功，则该过程在终点118处停止，并且应用程序必须重新开始。从不可还原堆栈上溢过程恢复的细节在图4中示出并且在下文中讨论。

流程图100中所示的方法所需的输入包括任务列、一组下一状态估计算法、以及备用内存空间80的映射。对于应用程序中的多个任务k，任务列 {T₀, T₁…,T_k-1}必须被以递减的堆栈起始地址的顺序设置。下一状态估计算法(E₀, E₁,…,E_k-1) 必须被设置用于k个任务中的每一个，其中这些算法由应用程序的程序员事先创建，并且基于已知数据诸如来自前一个执行循环的状态变量值估计这些任务中的每一个的输出。其它所需的输入、备用内存空间80的映射必须包括备用内存段84的内存堆栈位置和k个任务中的每一个的状态存储位置。

图3中流程图100的方法可被用来检测除堆栈上溢之外的堆栈下溢故障以及从该堆栈下溢故障恢复。这可以两种方式中的一种来完成。第二整套步骤可被执行用于下溢（例如，紧接在上溢检查的成功完成之后），或下溢检查可被直接合并到流程图100的方法中（通过在决策菱形106处检查上溢或下溢，并且如果任一种被检测到，则相应地继续进行恢复）。

流程图100的方法还可被用来在函数调用返回时而不是在任务切换时检测堆栈上溢/下溢以及从堆栈上溢/下溢中恢复。在这种情况下，框102将代表函数调用返回而不是任务切换。流程图100的方法的剩余部分与以上描述相比将不变化；状态数据备用将在框104处被捕获，堆栈上溢/下溢情况将在决策菱形106处被检查，并且从堆栈上溢/下溢情况的恢复将在框110处及以下执行。缓冲区上溢检查侵害也可触发上述操作。

图4是用于在上溢或下溢量超过可恢复的内存数据量的情况下从堆栈上溢或下溢中恢复的方法的流程图120。流程图120–将首先在上溢故障的背景下被讨论——图示出在图3的讨论中被引入的在框116内发生了什么。如上所讨论的，在框116处，作出从故障恢复的尝试，在所述故障中，来自任务T_i的堆栈上溢超过M个字节。在这样的情形下，决策菱形112通向框116。在决策菱形122处，确定任务T_i的堆栈是否上溢超过上一个任务T_k-1的堆栈段。这可通过检查上一个任务T_k-1的警告器值来确定。如果任务T_i 的堆栈上溢超过上一个任务T_k-1的堆栈段，则这是不可恢复的情形，并且该过程在终点118处停止，其中应用程序重新开始。

如果任务T_i的堆栈没有上溢超过上一个任务T_k-1的堆栈段，则该过程继续到框124，其中计数p被赋予值1。在框126处，任务T_i+p的下一个状态使用被应用到任务T_i+p的存储在备用内存空间80中的状态数据的估计算法E_i+p来估计。然后，任务T_i+p被终止，并且计数p增加1。在决策菱形128处，确定任务T_i的堆栈是否上溢超过任务T_i+p的堆栈段。如果否，则恢复完成，并且该过程继续到框108，在该框108中，任务T_d开始，如先前所讨论。

如果在决策菱形128处，确定任务T_i的堆栈上溢超过任务T_i+p的堆栈段，则该过程环回到框126，在该框126中，下一个较大的任务数的状态使用其估计算法来估计，该任务终止，并且计数再一次增加。在框126和决策菱形128之间的循环继续，直到堆栈上溢的范围已经被确定为止，并且对于堆栈数据已经由堆栈上溢盖写的所有任务的下一个状态已经被估计。然后，该过程下降到框108，在该框108中，针对执行下一个而安排的任务T_d开始。

先前提及的是，备用内存段84的大小M可被允许在程序执行期间增大。这可在如下流程图120中完成。每当流程图120的过程被执行时，M的值可增加到将被需要从刚刚遭遇的堆栈上溢（或下溢）恢复的内存量。也就是，如由计数p测量的堆栈上溢的任务的数量可被用来确定M的未来值。

以类似于先前所讨论的方式，流程图120的方法可被应用于下溢故障以及上溢故障。当被应用到堆栈下溢故障时，确定来自任务T_i的下溢量是否超过M个字节，并且如果是，则超过多少。该确定通过为隶属于前一个任务的堆栈递归地检查警告器值而作出，直到下溢的范围被识别为止。如果下溢扩展超过第一任务T₁的堆栈起点，则这是不可恢复的情形，并且应用程序将重新开始。

原型实施方式已经表明，所公开的方法使得堆栈上溢/下溢故障恢复成为可能，而资源消耗开支是最小的。从堆栈上溢/下溢故障中恢复而不重新启动硬件或软件，对于嵌入式汽车系统或不能容忍停机时间中断的任何其它系统来说，会是非常有利的。

上面的讨论仅公开并描述了本发明的示例性实施例。根据这样的讨论以及根据附图和权利要求，本领域的技术人员将容易地意识到，在不脱离如所附权利要求中所限定的本发明的精神和范围的情况下，能够在其中作出各种改变、修改和变型。