DE102012109614A1

DE102012109614A1 - Fehlerbehebung bei Stapel-Korruption in eingebetteten Softwaresystemen

Info

Publication number: DE102012109614A1
Application number: DE102012109614A
Authority: DE
Inventors: Dipankar Das
Original assignee: GM Global Technology Operations LLC
Current assignee: GM Global Technology Operations LLC
Priority date: 2011-11-16
Filing date: 2012-10-10
Publication date: 2013-05-16
Anticipated expiration: 2032-10-11
Also published as: US20130124917A1; CN103116532A; US8677189B2; DE102012109614B4; CN103116532B

Abstract

Ein Verfahren und ein System zum Wiederherstellen von Stapelüberlauf- oder Stapelunterlauffehlern, ohne dass dabei die Software oder Hardware neu gestartet wird. Bei jeder Aufgabenwechseloperation in einem Anwendungsprogramm wird ein Teil des Speicherstapels auf einen Backup-Bereich kopiert, so dass ein Teil des Stapels wiederhergestellt werden kann, falls dieser durch einen Stapelüberlauf- oder einen Stapelunterlauf-Fehler während der Ausübung der nächsten Aufgabe korrumpiert wird. Zustandsvariablen-Daten werden auf ähnliche Weise auf einen Backup-Bereich kopiert, so dass er dazu verwendet werden kann, um den Ausgang der nächsten Aufgabe wiederherzustellen oder abzuschätzen, falls dieser Aufgabe ein Fehler wiederfährt. Es werden Techniken zum Auswählen, welche Zustandsvariablen-Daten und welcher Bereich des Speicherstapels auf das Backup kopiert werden müssen und zum Detektieren eines Stapelüberlauf- oder Stapelunterlauf-Fehlers und zum Wiederherstellen von Zustandsvariablen- und Speicherdaten im Fall eines solchen Fehlers offenbart.

Description

HINTERGRUND DER ERFINDUNG
1. Gebiet der Erfindung
Diese Erfindung bezieht sich allgemein auf Softwarefehlerbehebung und insbesondere auf ein Verfahren zum Beheben von Stapelüberlauf- und Stapelunterlauffehlern in einem Softwaresystem, welches korrumpierte Speicherbereiche wiederherstellt, die fehlerbelastete oder korrumpierte Aufgabe (task) beendet und den Ausgang und den nächsten Zustand der fehlerbehafteten oder korrumpierten Aufgabe schätzt.
2. Diskussion des Standes der Technik
Moderne Fahrzeuge weisen automatische Systeme auf, die viele Aspekte der Leistungsfähigkeit des Fahrzeugs steuern. Diese Systeme verwenden Software, die zunehmend ausgeklügelter und komplex wird, wobei einige Fahrzeuge Systeme beinhalten, welche mehrere 10 Millionen Zeilen von Programmiercode beinhalten. Aufgrund der Komplexität der Software, der kurzen Zeit für einen Automobilhersteller, um ein Fahrzeug auf den Markt zu bringen, und dem weiten Bereich von Bedingungen, in denen ein Fahrzeug betrieben werden kann, treten gelegentlich Fehler auf, die von der Software ausgehen.
Eine gemeinhin bekannte Art von Fehler ist der Stapelüberlauf- oder Stapelunterlauffehler (gemeinhin bekannt als ”Stapel Überlauf/Unterlauf” oder ”Stapelkorruption”). In einem Stapelüberlauf- oder Stapelunterlauffehler versucht ein Programm, Daten auf einen Bereich eines Speicherstapels außerhalb eines vorgeschriebenen Bereiches – entweder über den Beginn des Stapels (Unterlauf) oder weit über dem maximalen Bereich des Stapels (Überlauf) zu schreiben. Stapelüberlauf- oder Stapelunterlauffehler resultieren gewöhnlicherweise in eine Korruption von einigen Systemdaten und/oder einen Bereich des Stapelspeichers. Obwohl Detektionstechniken für Stapel Überlauf/Unterlauf-Fehler gut bekannt sind, sind die Wiederherstellungstechniken unbefriedigend. In typischen Softwaresystemen ist die Antwort auf einen Stapel Überlauf/Unterlauf-Fehler entweder alle Softwareprogramme neu zu starten oder die Prozessor-Hardware selber neu zu starten. Da viele eingebettete Automotive Systeme in Echtzeit laufen, kann nicht hingenommen werden, dass sie für die relativ lange Zeit, die es braucht für einen Hardware- oder Software-Neustart, nicht einsatzbereit sind.
Demzufolge besteht ein Bedarf für eine Stapel Überlauf/Unterlauf-Fehlerbeseitigungstechnik, die keinen Hardware- oder Software-Neustart erfordert, die jedoch effizient genug ist im Hinblick auf Speicher- und Prozessor-Bedarf, um in der stark ressourcenbeschränkten Automobilumgebung verwendbar zu sein.
ZUSAMMENFASSUNG DER ERFINDUNG
Im Einklang mit den Lehren der vorliegenden Erfindung werden ein Verfahren und ein System zum Beseitigen von Stapel Überlauf/Unterlauf-Fehlern ohne Neustarten der Software oder Hardware offenbart. Bei jeder Aufgabenwechseloperation in einem Anwendungsprogramm wird ein Teil des Speicherstapels auf einen Backup-Bereich kopiert, so dass der Bereich des Stapels wiederhergestellt werden kann, falls er durch einen Stapelüberlauf- oder Stapelunterlauffehler während der Ausführung der nächsten Aufgabe in der Folge korrumpiert wird. Zustandsvariablen-Daten werden auf ähnliche Art auf einen Backup-Bereich kopiert, sodass diese dann dazu verwendet werden können, um den Ausgang der nächsten Aufgabe wiederherzustellen oder zu schätzen, falls diese Aufgabe einen Fehler erfährt. Es werden Techniken offenbart zum Auswählen, welche Zustandsvariablen-Daten und welcher Bereich des Speicherstapels auf das Backup kopiert werden sollen und zum Detektieren eines Stapelüberlauf/-unterlauffehlers und zum Wiederherstellen von Zustandsvariablen und Speichertdaten im Fall eines solchen Fehlers.
Weitere Merkmale der vorliegenden Erfindung werden aus der folgenden Beschreibung und den beigefügten Patentansprüchen in Verbindung mit den beigefügten Figuren deutlich.
KURZE BESCHREIBUNG DER FIGUREN
1 ist ein Blockdiagramm eines Systems, das in der Lage ist nach einer Stapelkorruption ohne Neustarten von Software oder Hardware wiederhergestellt zu werden;
2 ist ein Diagramm eines Speicherstapels, der Teile des Stapels zeigt, welche für drei Aufgaben in einem Ausführungszyklus verwendet werden;
2A ist ein Diagramm des Speicherstapels aus der 2, welches ein fehlerfreies Verhalten bei einem Aufgabenwechsel zeigt;
2B ist ein Diagramm des Speicherstapels aus der 2, welches die Wiederherstellung nach einem Stapelüberlauffehler bei einem Aufgabenwechsel zeigt;
3 ist ein Flussdiagramm für ein Verfahren zum Wiederherstellen nach einem Stapel Überlauf/Unterlauf-Fehler ohne Neustarten von Software oder Hardware; und
4 ist ein Flussdiagramm für ein Verfahren zum Wiederherstellen nach einem Stapel Überlauf/Unterlauf-Fehler, bei dem der Betrag an Überlauf den Betrag an wiederherstellbaren Speicherdaten überschreitet.
DETAILLIERTE BESCHREIBUNG DER AUSFÜHRUNGSBEISPIELE
Die folgende Diskussion der Ausführungsformen der Erfindung, die auf das Wiederherstellen von Stapelüberlauf/-unterlauffehlern in eingebetteten Softwaresystemen gerichtet ist, ist rein beispielhafter Natur und in keiner Weise dazu gedacht, die Erfindung oder ihre Anwendungen oder Verwendungen zu begrenzen. Insbesondere bezieht sich viel der folgenden Diskussion auf Echtzeitsteuersysteme im Automobilbereich, die offenbarten Verfahren und Systeme sind jedoch gleichermaßen auf jede andere Art von Softwaresystem anwendbar, welches von einer Wiederherstellung nach einer Stapelkorruption profitieren könnte.
In Softwaresystemen tritt Stapel Überlauf oder -unterlauf auf, wenn ein Programm auf einer Speicheradresse auf den Call-Stack des Programms außerhalb der dafür vorgesehenen Datenstruktur schreibt, welcher gewöhnlicherweise ein Buffer mit einer festen Länge ist. Stapelüberläufe treten auf, wenn zu viele Daten (von Frames oder Funktionen, Interrupts oder Traps) in den Stapel gedrückt werden. Stapelunterläufe treten auf, wenn es zu einem Überlauf des lokalen Buffers kommt. Stapelüberläufe und -unterläufe können von Softwarefehlern oder von Angriffen von Hackern verursacht werden. In jedem Fall resultieren sie fast immer in der Korruption von benachbarten Daten auf dem Stapel und wenn dies nicht detektiert wird, wird dies oft dazu führen, dass das Programm abstürzt oder nicht korrekt arbeitet. Demzufolge besteht ein großer Wunsch danach, Stapelkorruption zu detektieren und zu adressieren, bevor diese weitere Probleme verursachen.
Es ist eine gemeinhin bekannte Software Design Technik, während der Programmausführung Stapelüberläufe und -unterläufe zu prüfen. Ein Verfahren zum Detektieren von Stapelüberläufen ist der Gebrauch von Stapel-Canaries. Stapel Canaries werden so genannt, weil sie wie ein Kanarienvogel (Canary) in einer Kohlemine arbeiten, die frühzeitig ein Problem anzeigen, und dazu verwendet werden, eine Stapelkorruption zu detektieren, bevor die fehlerhafte Code-Ausführung auftreten kann. Dieses Verfahren arbeitet damit, dass ein bekannter Datenwert, welcher zufällig beim Programmstart ausgewählt wird, im Speicher unmittelbar vor dem Stapel Return Pointer platziert wird. Definitionsgemäß bedeutet einen Stapelüber/-unterlauf, dass Daten außerhalb des vorgeschriebenen Adressbereiches geschrieben wurden, so dass bei einer Stapelkorruption der Canary-Wert überschrieben werden wird. Der Canary-Wert wird geprüft, um sicher zu gehen, dass er sich nicht geändert hat, bevor eine Routine den Return Pointer auf dem Stapel verwendet. Wenn der keinen anderen als den erwarteten Wert aufweist, dann hat wahrscheinlich ein Stapelunterlauf stattgefunden. Eine ähnliche Technik kann verwendet werden, um Stapelüberläufe zu detektieren. Stapel-Canaries können bei Function-Call-Returns geprüft werden, wie oben beschrieben oder bei weniger häufigen Auftreten wie zum Beispiel bei Aufgabenwechsel.
Sobald ein Stapelüberlauf oder Stapelunterlauf detektiert wird, wobei Canary-Werte geprüft werden oder durch andere Mittel, berichten die meisten Programme typischerweise die Überlauf/Unterlauf-Bedingung und danach werden alle Anwendungsprogramme beendet und/oder die Prozesse erneut gestartet. Viele eingebettete Automotive Softwaresysteme arbeiten allerdings in Echtzeit und können nicht für die Zeitdauer, die es braucht, um einen Neustart der Softwareprogramme oder des Prozessors auszuführen, inoperativ bleiben. Solche Systeme würden von einer Vorgehensweise profitieren, welche die meisten Stapelüberläufe und -unterläufe detektieren und wiederherstellen kann, ohne dabei die Programme oder den Prozessor neu zu starten.
1 ist ein Blockdiagramm eines Systems 10, das in der Lage ist, einen Stapelüberlauf/-unterlauf ohne Neustarten der Software oder der Hardware wiederzuherzustellen. Block 12 ist ein Anwendungsprogramm, welches auf einem Prozessor 32 läuft zusammen mit allen anderen Elementen des Systems 10. Der Prozessor 32 kann ein Mikrocontroller für ein eingebettete Steuersystemanwendung oder allgemeiner ein Vielzweck-Mikroprozessor oder ein elektronisches Steuergerät sein. Wann auch immer eine Aufgabe in dem Applikationsprogramm in den Kasten 12 vervollständigt ist, wird die Steuerung an den Block 14 transferiert, wobei Systemzustandsdaten und Speicherdaten aufgenommen und in den Datenspeicher 16 abgespeichert werden. Der Datenspeicher 16 speichert einen Checkpoint für verschiedene Zustandsvariablen und speichert eine Backup-Kopie von bestimmten Bereichen des Systemspeichers – sowohl in der Richtung des Stapelüberlaufes als auch des Stapelunterlaufes für den Aufgabenstapel – wie unten detailliert diskutiert werden wird. Die Zustandsdatenaufnahme in dem Kasten 14 kann nicht nur zwischen der Ausführung von zwei Aufgaben eingeleitet werden, sondern auch zwischen einer Aufgabe und einer Interrupt Service Routine oder zwischen einer Interrupt Service Routine und einer Aufgabe.
In der Raute 18 wird eine Stapelüberlauf- oder Stapelunterlauf-Bedingung geprüft, entweder durch Prüfen von Canaries-Werten oder durch ein anderes geeignetes Verfahren. Falls kein Stapelüberlauf oder Unterlauf in der Raute 18 detektiert wird, kehrt die Steuerung zu dem Programm in den Kasten 12 zurück und das Programm fährt mit seiner Ausführung fort. Falls in der Raute 18 ein Stapelüberlauf oder -unterlauf detektiert wird, dann werden die fehlerhafte Aufgabe in dem Kasten 20 und der korrumpierte Speicherbereich in dem Kasten 20 identifiziert. Die fehlerhafte Aufgabe ist als die Aufgabe bekannt, welche ausgeführt wurde, bevor die Steuerung zum Block 14 transferiert wurde. Der korrumpierte Speicherbereich ist von der Aufgabe abhängig, welche den Stapelüberlauf oder -unterlauf verursachte, da der korrumpierte Bereich derjenige ist, der an den Stapel, der über läuft in die Richtung des Stapelwachstums, angrenzt, oder unterhalb des Stapelsbeginns unterläuft, was in einer späteren Figur gezeigt werden wird. Sobald der korrumpierte Speicherbereich im Block 20 identifiziert ist, kann er im Block 22 wiederhergestellt werden, indem er mit einem Speicherblock einer festen Größe, welche auf einen sicheren Bereich in dem Datenspeicher 16 kopiert wurde, bevor die fehlerhafte Aufgabe aufgerufen wurde, überschrieben wird. Block 24 ist das reparierte Softwaresystem, das den wiederhergestellten Speicherblock enthält.
Falls während der Wiederherstellung des korrumpierten Speicherbereichs im Block 22 bestimmt wird, dass wichtige Call Stack Daten für die Aufgabe, welche die Stapelkorruption verursacht hat, überschrieben wurden, dann wird die fehlerhafte Aufgabe im Block 26 beendet und ihr Ausgang und nächster Zustand werden wiederhergestellt oder geschätzt. Der nächste Anwendungsausgang und Zustand können von dem Anwendungszustand vor dem Aufruf der fehlerhaften Aufgabe geschätzt werden, welche aus dem Datenspeicher 16 verfügbar ist. Block 28 enthält den wiederhergestellten geschätzten Ausgang und den nächsten Zustand für den reparierten Schritt. Operationen innerhalb des Kastens 30 werden bei jedem Aufgabenwechsel ausgeführt im Anwendungsprogramm im Block 12 und werden unten detaillierter diskutiert werden.
Das System 10 kann auch dazu verwendet werden, um bei Funktionsaufrufen Stapelüberläufe oder -unterläufe zu detektieren und wiederherzustellen anstelle eines Aufgabenwechsels. In diesem Fall würde die Steuerung zu dem Block 14 aufgrund eines Funktionsaufrufs transferiert werden. Das Übrige des Systems 10 bleibt gegenüber der obigen Beschreibung ungeändert; ein Zustandsdaten Backup würde in den Datenspeicher 16 vor der Funktionsausführung abgelegt werden, eine Stapelüberlauf/Unterlaufbedingung würde in der Raute 18 nach der Funktionsausführung geprüft werden und eine Wiederherstellung von dem Stapelüberlauf/Unterlaufbedingung würde in den Blöcken 20–28 ausgeführt werden.
2 ist ein Diagramm eines Speicherbereichs 36, der Elemente zeigt, die für drei Aufgaben in einem Ausführungszyklus eines Programms verwendet werden. Stapelsegment 40 enthält Stapeldaten für eine Aufgabe 0 und besteht aus einer besetzten Aufgabe 0 Stapel 42, einem unbesetzten Aufgabe 0 Stapel 44 und einer Aufgabe 0 Canary 46. Wie hier gezeigt wird, ist das Stapelsegment 40 ein Bereich mit einer festen Größe, der von unten her geschrieben wird, die Stapeldaten, die gegenwärtig in der besetzten Aufgabe 0 Stapel 42 gespeichert sind, verbrauchen einigen Raum, die Aufgabe 0 Canary 46 verbraucht einen kleinen Betrag an Platz auf der Spitze des Segments 40 und der Rest des Speichers in dem Stapelsegment 40 ist die unbesetzte Aufgabe 0 Stapel 44. Die Struktur des Stapelsegments 40 wird für eine Aufgabe 1 Stapelsegment 50 repliziert, welche aus einer unbesetzten Aufgabe 1 Stapel 52, einer unbesetzten Aufgabe 1 Stapel 54 und einer Aufgabe 1 Canary 56 besteht. Die Struktur wird darüber hinaus für eine Aufgabe 2 Stapelsegment 60 repliziert, welche aus einer besetzten Aufgabe 2 Stapel 62, einer unbesetzten Aufgabe 2 Stapel 64 und einer Aufgabe 2 Canary 66 besteht. Der Speicherplatz 36 beinhaltet des Weiteren ein Betriebssystem (O/S) Segment 70, welches aus einem O/S Stapel 72 und einem (O/S) Canary 74 besteht.
Speicherplatz 80 ist ein Random Access Speicherplatz, der dazu verwendet wird, um Backup-Kopien vom Speicher, der in dem Raum 36 höher angeordnet ist und auch um Zustandsvariablen Checkpoint Daten zu speichern. Der Backup-Speicherplatz 80 stellt den Speicherort für den Datenspeicher 16 aus der 1 dar. Der Betrieb des Backup-Speicherplatzes 80 wird bei der Diskussion der 2A und 2B unten weiter erklärt. Es wird angemerkt, dass der Backup-Speicherplatz 80 auch an der Spitze des Speicherplatzes 36 im globalen Speicherraum 90 platziert werden könnte.
Der globale Speicherraum 90 wird im Block 12 von dem Anwendungsprogramm verwendet, um kritische Variablen, beispielsweise Zustandsvariablen zu speichern, auf welche von jeder Aufgabe in dem Ausführungszyklus zugegriffen werden muss. Der Betrieb des globalen Speicherraums 90, sofern er sich auf das Stapel-Überlauf/Unterlauf-Wiederherstellungsverfahren, das hier offenbart wird, bezieht, wird auch bei der Diskussion der 2A und 2B unten erklärt werden.
2A ist ein Diagramm eines Speicherraums 36, das ein fehlerfreies Verhalten bei einem Aufgabenwechsel zwischen Aufgabe 2 und Aufgabe 0 veranschaulicht. 2A veranschaulicht die Präventivmaßnahmen, die unternommen werden, um einen Schutz vor einem Stapelüberlauf-Fehler zu gewährleisten. Ähnliche Maßnahmen, die der Klarheit halber nicht gezeigt werden, können vorgenommen werden (Aufnehmen von Speicher unterhalb eines Aufgaben-Stapels), um gegen Stapel-Unterlauffehler zu schützen. Da Aufgabe 0 die nächste Aufgabe ist, die ausgeführt werden muss, ist es wünschenswert, eine exakte Kopie eines Teils des Speichers oberhalb des Aufgabe 0 Speichersegments 40 anzufertigen, so dass eine Wiederherstellung im Fall, dass die Aufgabe 0 bei ihrer Ausführung einen Stapelüberlauf verursacht, möglich ist. Demzufolge wird vor der Ausführung der Aufgabe 0 Segment 58, das M Bytes an Speicher von der besetzten Aufgabe 1 Stapel 52 in das Backup-Speichersegment 84 in den Backup-Speicherraum 80 kopiert. In einer Ausführungsform wird die Größe M der Segmente 58 und 84 vor der Programmausführung bestimmt und bleibt fest für jeden Speicher-Backup und für alle Wiederherstelloperationen. In einer anderen Ausführungsform wird die Größe M mit einem Anfangswert eingestellt und kann, falls dies während der Programmausführung notwendig ist, wachsen, was unten diskutiert werden wird. Vor Ausführung der Aufgabe 0 ist es wünschenswert, eine Checkpointkopie der Aufgabe 0 Zustandsvariablen zu generieren, für den Fall, dass diese bei einer späteren Wiederherstellung benötigt werden. Demzufolge werden die Aufgabe 0 Zustandsvariablen Datensegmente 92 und 94, die die Zustandsvariablen darstellen, die vorher bei der Aufgabe 0 berechnet wurden, in den Aufgabe 0 Zustandsspeicherort 82 in dem Backup-Speicherraum 80 kopiert.
Der Backup-Speicherraum 80 ist mit einem einzelnen Backup-Speichersegment 84 ausgestattet, welches dazu verwendet wird, um einen Teil des Speichers, der gerade darüber liegt, (bei Überlauf), egal welche Aufgabe gerade am beginnen ist, zu speichern. Ein zweites Backup-Speichersegment (nicht gezeigt) würde dazu verwendet werden, um einen Bereich des Speichers, der sich gerade darunter befindet (für Unterlauf) zum Wiederherstellen zu verwenden, egal welche Aufgabe gerade stattfindet. Der Backup-Speicherraum 80 beinhaltet viele Zustandsvariablen-Speicherorte, wobei eine für jede Aufgabe vorgesehen ist, beispielsweise einen Aufgabe 0 Zustandsspeicherort 82. In diesem Beispiel können die Inhalte des Aufgabe 0 Zustandsspeicherortes 82 und des Backup-Speichersegments 84 für eine spätere Wiederherstellung verwendet werden, falls die Ausführung der Aufgabe 0 in der Folge als Verursacher eines Stapelüberlaufs gefunden wurde. Bevor die Ausführung der Aufgabe 0 begonnen wird, wird eine Prüfung ausgeführt, um zu bestimmen, ob die Aufgabe, die zuletzt ausgeführt wurde, Aufgabe 2, einen Stapelüberlauf verursacht hat. Die Aufgabe 2 Canary 66 wird geprüft und es wird bestimmt, dass sie den erwarteten Wert aufweist, was bedeutet, dass kein Stapelüberlauf aufgetreten ist, so dass die Steuerung im Block 12 für die Ausführung der Aufgabe 0 zu den Anwendungsprogrammen zurückkehren kann.
2B ist ein Diagramm des Speicherraums 36, der die Wiederherstellung von einem Stapelüberlauffehler bei einem Aufgabenwechsel zwischen der Aufgabe 2 und der Aufgabe 0 veranschaulicht. Dasselbe Konzept könnte wiederum auch für die Wiederherstellung eines Stapelunterlauffehlers verwendet werden, aber in der 2B wird der Klarheit halber nur der Überlauf gezeigt. In diesem Fall wird bei der Prüfung der Aufgabe 2 Canary 66 bestimmt, dass dieser überschrieben wurde, was bedeutet, dass ein Stapelüberlauf während der Ausführung der Aufgabe 2 aufgetreten ist. In herkömmlichen Softwaresystemen würde der Stapelüberlauf einen Systemabsturz verursachen und einen Systemneustart vonnöten machen, welcher wie oben diskutiert bei Echtzeit-Systemen eine inakzeptable Ruhepause verursachen würde. Die Verwendung der hier offenbarten Wiederherstellungsmethodik macht es jedoch möglich, den Systemabsturz oder Neustart zu vermeiden.
In der 2B beginnt die Ausführung der Aufgabe 0 nicht, da die Aufgabe 2 Canary 66 als korrumpiert bestimmt wird. Anstelle dessen müssen Daten aus dem Backup-Speicherraum 80 zurück auf eine geeignete Stelle in den Speicherraum 36 kopiert werden. Ein Element für die Wiederherstellung von einem Stapelüberlauf ist es, die Zustandsvariablen-Daten von dem vorhergehenden Checkpoint wieder zu besetzen. Da die Ausführung der Aufgabe 2 als fehlerhaft bekannt war, werden die Zustandsvariablen-Daten von einem Aufgabe 2 Zustandsspeicherort 86 zurück zu einem Aufgabe 2 Zustandsvariablendatensegment 96 in dem globalen Speicherraum 90 kopiert.
Die Inhalte des Backup-Speichersegments 84 müssen auch auf den geeigneten Ort in dem Speicherraum 36 kopiert werden. Das Backup-Speichersegment 84 wäre vor Ausführung der fehlerhaften Aufgabe 2 mit M Bytes Speicher von dem Stapelort unmittelbar über dem Aufgabe 2 Stapelsegment 60 besetzt, welcher der O/S Stapel 72 ist. Da ein Teil des O/S Stapels 72 bei dem Stapelüberlauf während der Ausführung der Aufgabe 2 überschrieben worden ist, muss demzufolge das Backup-Speichersegment 84 zurück auf das Segment 76 in dem O/S Stapel 72 kopiert werden. Mit Zustandsvariablen-Daten und Speicher, der von dem Backup-Speicherraum 80 wiederhergestellt wurde, ist es dann möglich, mit der Ausführung der Aufgabe 0 fortzufahren.
3 ist ein Flussdiagramm 100 für ein Verfahren zum Wiederherstellen von einem Stapelüberlauf, ohne dass dabei Software oder Hardware neu gestartet werden müssen, wobei die oben beschriebenen Speicher- und Zustandsvariablen-Backup-Kopiertechniken verwendet werden. Die Diskussion der 3, sofern sie sich auf die Detektion von Stapelunterlauf und der darauf folgenden Wiederherstellung bezieht, erfolgt weiter unten. Die Diskussion des Flussdiagramms 100 beinhaltet Bezugnahmen auf Elemente des Speicherraumes 36 der 2, 2A und 2B. Im Kasten 102 ist ein Anwendungsprogramm bereit, um von einer Aufgabe T_i zu einer Aufgabe T_d zu wechseln. Wie oben diskutiert, könnte der Kasten 102 auch einen Wechsel von einer Interrupt Service Routine (ISR) zu einer Aufgabe oder ein Wechsel von einer Aufgabe zu einer ISR darstellen. Im Kasten 104 werden Zustandsvariablen-Daten für die Aufgabe T_d in ein Segment des Backup-Speicherraums 80 gespeichert, welcher für die Aufgabe T_d Zustandsdaten vorgesehen ist. Ferner werden M Bytes Speicher im Kasten 104 von oberhalb des Stapels der Aufgabe T_d zu einem Segment des Backup-Speicherraums 80 kopiert, welcher für eine Speicherkopie vorgesehen ist, beispielsweise das Backup-Speichersegment 84.
In der Entscheidungsraute 106 wird bestimmt, ob ein Stapelüberlauf bei der Aufgabe T_i aufgetreten ist. Falls kein Stapelüberlauf bei der Aufgabe T_i aufgetreten ist, geht das Verfahren zum Kasten 108 über, wobei die Aufgabe T_d startet.
Falls ein Stapelüberlauf bei der Aufgabe T_i aufgetreten ist, dann geht das Verfahren von der Entscheidungsraute 106 zum Kasten 110 über, wobei Zustandsdaten für die Aufgabe T_i wiederhergestellt werden. Zustandsdaten für die Aufgabe T_i können durch direktes Kopieren von zugeordneten Bereichen in dem Backup-Speicherraum 80 auf die ordnungsgemäßen Orte in dem globalen Speicherraum 90 wiederhergestellt werden, was eingangs diskutiert wurde. Es ist ebenso möglich, einen verfeinerten Wert der Zustandsdaten für die Aufgabe T_i durch Anwenden eines Schätzungsalgorithmus E_i für die Zustandsdaten für die Aufgabe Ti, welcher in dem Backup-Speicherraum 80 gespeichert ist. Schätzungsalgorithmen werden weiter unten diskutiert. Optional können Parameterdaten für die Aufgabe T_i in dem Kasten 110 gespeichert werden, um eine Fehlerdiagnose nach Eintritt des Fehlerfalls zu unterstützen, wobei die Parameterdaten für die Aufgabe T_i den Wert von i (welche anzeigt, welche Aufgabe einen Fehler erfahren hat), die Werte aller Eingänge für die Aufgabe T_i und die Zustandsvariablen-Daten für die Aufgabe T_i beinhaltet.
Letztendlich bevor der Kasten 110 verlassen wird, wird die Aufgabe T_i beendet. An diesem Punkt nachdem ein Stapelüberlauf für die Aufgabe T_i aufgetreten ist, wird die Aufgabe T_i abgebrochen und die Zustandsdaten für die Aufgabe T_i wurden wiederhergestellt. Es ist dann notwendig, die Speicherdaten von der von dem Backup-Speicherraum 80, auf welchem Bereich auch immer des Speicherraums 36, der durch den Stapelüberlauf korrumpiert worden ist, wiederherzustellen. In der Entscheidungsraute 112 wird bestimmt, ob der Stapelüberlauf von der Aufgabe T_i M Bytes überschreitet. Dies wird durch Prüfen, ob das letzte Wort des Backup-Speichersegments 84 dasselbe ist, wie das an dem Ort, auf dem es wiederhergestellt werden soll. Falls der Stapelüberlauf von der Aufgabe T_i nicht M Bytes überschreitet, dann kann im Kasten 114 das Backup-Speichersegment 84 an den Ort kopiert werden, an welchem es wiederhergestellt werden soll und daraufhin die Aufgabe T_d im Kasten 108 gestartet werden.
Falls in der Entscheidungsraute 112 bestimmt wird, dass der Stapelüberlauf von der Aufgabe T_i M Bytes überschreitet, dann wird im Kasten 116 ein Versuch gemacht, von dem nicht wiederherstellbaren Stapelüberlauf eine Wiederherstellung zu machen. Wenn der Versuch erfolgreich ist, dann geht das Verfahren zu dem Kasten 108 über, wobei die Aufgabe T_d gestartet wird. Wenn der Versuch, von dem nicht wiederherstellbaren Datenüberlauf eine Wiederherstellung zu bekommen im Kasten 116 nicht erfolgreich ist, dann hält das Verfahren an dem Haltepunkt 116 und das Anwendungsprogramm muss neu gestartet werden. Details für die Wiederherstellung von nicht wiederherstellbaren Stapelüberlauf Verfahren werden in der 4 gezeigt und unten diskutiert.
Die Eingaben, die für das in dem Flussdiagramm 100 gezeigte Verfahren notwendig sind, beinhalten eine Liste von Aufgaben, einen Satz von Nächstzustand-Schätzungsalgorithmen und ein Mapping des Backups-Speicherraums 80. Für eine Anzahl von Aufgaben k in dem Anwendungsprogramm muss eine Liste von Aufgaben {T₀, T₁, ..., T_K-1} in der Reihenfolge der absteigenden Stapel-Startadresse bereitgestellt werden. Nächstzustands-Schätzungsalgorithmen (je E₀, E₁, ..., E_K-1) müssen für jede der K Aufgaben bereitgestellt werden, wobei die Algorithmen im Vorhinein von einem Programmierer des Applikationsprogramms erzeugt werden und die Ausgabe für jede der Aufgaben basierend auf bekannten Daten schätzt, beispielsweise Zustandsvariablenwerte von einem vorangegangenem Ausführungszyklus. Die andere erforderliche Eingabe ist das Mapping des Backupspeicherraums 80 und muss den Speicherstapelplatz des Backup-Speichersegments 84 und der Zustandsspeicherorte für jede der K Aufgaben umfassen.
Das Verfahren aus dem Flussdiagramm 100 in der 3 kann dazu verwendet werden, um Stapelunterlauf Fehler zu detektieren und wiederherzustellen zusätzlich zu Stapelüberläufen. Dies kann auf zwei Arten geschehen. Entweder wird ein zweiter kompletter Satz von Schritten für Unterläufe ausgeführt, (unmittelbar nachdem eine erfolgreiche Vervollständigung der Überlaufprüfung beispielsweise stattgefunden hat) oder die Unterlaufprüfungen können direkt in das Verfahren des Flussdiagramms 100 inkorporiert werden, indem sowohl für einen Überlauf als auch einen Unterlauf in der Entscheidungsraute 106 geprüft wird und dementsprechend mit dem Verfahren einer Wiederherstellung fortgefahren wird, wenn eine detektiert wird.
Das Verfahren des Flussdiagramms 100 kann auch dazu verwendet werden, bei Function-Call Returns Stapelüberläufe/-unterläufe zu detektieren und wiederherzustellen anstelle von Aufgabenwechseln. In diesem Fall würde der Kasten 102 einen Function-Call Return anstelle eines Aufgabenwechsels darstellen. Das übrige an dem Verfahren aus dem Flussdiagramm 100 wäre ungeändert zu der Beschreibung oben; ein Zustandsdaten Backup würde in dem Kasten 104 aufgenommen, eine Stapelüberlauf/Unterlaufbedingung würde in der Entscheidungsraute 106 geprüft werden und eine Wiederherstellung von einem Stapelüberlauf/Unterlaufbedingung würde in dem Kasten 110 und unten ausgeführt werden. Buffer-Überlauf-Check-Verletzungen können ebenfalls die vorgenannten Operationen auslösen.
4 ist ein Flussdiagramm 120 für ein Verfahren zum Wiederherstellen von einem Stapelüberlauf oder -unterlauf, bei dem der Betrag des Überlaufs oder Unterlaufs den Betrag an wiederherstellbaren Speicherdaten überschreitet. Das Flussdiagramm 120, was zuerst im Kontext mit einem Überlauffehler diskutiert werden wird, veranschaulicht, was innerhalb des Kastens 116, der bei der Diskussion der 3 eingeführt wurde, geschieht. Wie oben diskutiert wurde, wird im Kasten 116 ein Versuch gemacht, um nach einem Fehler, bei dem der Stapelüberlauf von der Aufgabe T_i M Bytes überschreitet, wiederherzustellen. In einer solchen Situation führt die Entscheidungsraute 112 zu dem Kasten 116. In der Entscheidungsraute 122 wird bestimmt, ob der Stapel der Aufgabe T_i weit über das Stapel-Segment der letzten Aufgabe T_k-1 übergelaufen ist. Dies kann durch Prüfen des Canary-Werts für die letzte Aufgabe T_k-1 bestimmt werden. Wenn der Stapel der Aufgabe T_i weit über das Stapelsegment der letzten Aufgabe T_k-1 übergelaufen ist, besteht eine nicht wiederherstellbare Situation und das Verfahren hält an dem Haltepunkt 118, wo das Anwendungsprogramm neu gestartet wird.
Wenn der Stapel der Aufgabe T_i nicht unter das Stapelsegment der letzten Aufgabe T_k-1 übergelaufen ist, dann geht das Verfahren zu dem Kasten 124 über, wobei einem Zähler p ein Wert von 1 gegeben wird. Im Kasten 126 wird der nächste Zustand der Aufgabe T_i+P unter Verwendung des Schätzungsalgorithmus E_i+P, der auf die Zustandsdaten für die Aufgabe T_i+P, welche in dem Backup-Speicherraum 80 abgespeichert ist, angewandt wird, geschätzt. Daraufhin wird die Aufgabe T_i+P abgebrochen und der Zähler p wird mit 1 inkrementiert. In der Entscheidungsraute 128 wird dann bestimmt, ob der Stapel der Aufgabe T_i weit über das Stapelsegment der Aufgabe T_i+p übergelaufen ist. Wenn dies nicht der Fall ist, dann ist die Wiederherstellung vollständig und das Verfahren geht über zum Kasten 108, wobei die Aufgabe T_d gestartet wird, wie eingangs diskutiert.
Wenn in der Entscheidungsraute 128 bestimmt wird, dass der Stapel der Aufgabe T_i weit über das Stapelsegment der Aufgabe T_i+P übergelaufen ist, dann geht das Verfahren zurück zu dem Kasten 126, wobei der Zustand der nächsthöheren Aufgabenzahl unter Verwendung seines Schätzungsalgorithmus geschätzt wird, dass die Aufgabe beendet wird und der Zähler wiederum inkrementiert wird. Die Verknüpfung zwischen dem Kasten 126 und der Entscheidungsraute 128 besteht so lange fort, bis das Ausmaß des Stapelüberlaufs bestimmt worden ist und nächste Zustände für alle Aufgaben, bei denen durch den Stapelüberlauf Stapeldaten überschrieben worden sind, geschätzt sind. Danach geht das Verfahren zu dem Kasten 108, wobei die Aufgabe T_d, welche als die nächstauszuführende Aufgabe angesehen wird, gestartet wird.
Es wurde oben erwähnt, dass die Größe M des Backup-Speichersegments 84 während der Programmausführung wachsen kann. Dies kann in dem Flussdiagramm 120 wie folgt erzielt werden. Jedes Mal, wenn das Verfahren des Flussdiagramms 120 ausgeführt wird, wird der Betrag an Speicher, der notwendig gewesen wäre, um von dem Stapelüberlauf (oder Unterlauf), der gerade aufgetreten ist, wiederhergestellt zu werden, erhöht. Das ist die Anzahl der Aufgaben, die einen, bei denen ihr Stapel übergelaufen ist, was über den Zähler p gemessen wird und was zur Bestimmung eines zukünftigen Wertes von M verwendet werden kann.
In einer ähnlichen Art zu der oben diskutierten, kann das Verfahren aus dem Flussdiagramm 120 auf Unterlauffehler und auf Überlauffehler angewendet werden. Wenn es auf Stapelunterlauffehler angewendet wird, wird eine Bestimmung gemacht, ob der Unterlaufbetrag von der Aufgabe T_i M Bytes überschreitet und wenn dies der Fall ist, um wie viel. Die Bestimmung wird durch rekursives Prüfen eines Canary-Werts für den Stapel, der zu der vorangegangenen Aufgabe gehört, gemacht, solange bis das Ausmaß des Unterlaufs identifiziert ist. Falls der Unterlauf unter den Stapelbeginn der ersten Aufgabe T₁ geht, dann besteht eine nicht wiederherstellbare Situation und das Anwendungsprogramm würde neu gestartet werden.
Prototyp Implementierungen haben gezeigt, dass die hier offenbarten Verfahren eine Stapelüberlauf/Unterlauf-Fehlerwiederherstellung ermöglichen, wobei der Ressourcenaufwand dafür minimal ist. Das Wiederherstellen von Stapelüberlauf/Unterlauffehlern, ohne dabei Hardware oder Software neustarten zu müssen, kann für eingebettete Automotivsysteme sehr vorteilhaft sein oder für an ein anderes System, welches keine zeitlichen Unterbrechungen toleriert.
Die vorhergehende Diskussion zeigt und beschreibt rein exemplarische Ausführungsbeispiele der vorliegenden Erfindung. Ein Fachmann kann leicht aus der Diskussion und den beigefügten Figuren und Patentansprüchen erkennen, dass zahlreiche Änderungen, Modifikationen und Variationen gemacht werden können, ohne dabei den Geist und den Bereich der Erfindung zu verlassen, wie er mit den folgenden Patentansprüchen definiert ist.

Claims

Ein Verfahren zum Wiederherstellen von Stapelüberlauf- oder Stapelunterlauffehlern in einer Softwareanwendung, die auf einem Prozessor läuft, wobei das Verfahren umfasst: – Konfigurieren eines physischen Speicherraums, um einen Stapelspeicher und einen Backup-Speicherplatz zu umfassen; – Kopieren eines Teils des Stapelspeichers und eines Satzes von Zustandsvariablen auf den Backup-Speicherplatz bei einem Aufgabenwechsel in einem Anwendungsprogramm; – Bestimmen, ob eine Stapelüberlauf- oder Stapelunterlauf-Fehlerbedingung während der Ausführung einer vorhergehenden Aufgabe aufgetreten ist; – Wiederherstellen eines gesicherten Satzes von Zustandsvariablen für die vorangegangene Aufgabe, falls der Stapelüberlauf- oder Stapelunterlauffehler während der Ausführung der vorangegangenen Aufgabe aufgetreten ist; – Beenden der vorangegangenen Aufgabe falls der Stapelüberlauf- oder Stapelunterlauffehler während der Ausführung der vorangegangenen Aufgabe aufgetreten ist; – Wiederherstellen eines gesicherten Bereichs des Stapelspeichers falls der Stapelüberlauf- oder Stapelunterlauffehler während der Ausführung der vorangegangenen Aufgabe aufgetreten ist; und – Starten einer nächsten Aufgabe.
Verfahren nach Anspruch 1, wobei das Kopieren eines Teils auf den Backup-Speicherplatz das Kopieren eines Stapelspeichersegments oberhalb eines Stapel-Canary für die nächste Aufgabe und Kopieren eines Stapelspeichersegments unterhalb eines Stapel-Canary für die nächste Aufgabe auf den Backup-Speicherplatz beinhaltet
Verfahren nach Anspruch 1, wobei das Kopieren eines Satzes von Zustandsvariablen auf den Backup-Speicherplatz das Kopieren von Zustandsvariablen für die nächste Aufgabe auf den Backup-Speicherplatz beinhaltet.
Verfahren nach Anspruch 1, wobei das Bestimmen, ob ein Stapelüberlauf- oder Stapelunterlauffehler während der Ausführung einer vorangegangenen Aufgabe das Prüfen eines Canary-Werts für die vorangegangene Aufgabe beinhaltet.
Verfahren nach Anspruch 1, wobei das Wiederherstellen eines gesicherten Satzes von Zustandsvariablen für die vorangegangene Aufgabe das Schätzen eines verfeinerten Wertes von dem gesicherten Satz von Variablen unter Verwendung eines Schätzungsalgorithmus für die vorangegangene Aufgabe beinhaltet.
Verfahren nach Anspruch 1, wobei das Wiederherstellen eines gesicherten Bereichs von Stapelspeicher das Bestimmen beinhaltet, ob ein Bereich von Stapelüberlauf oder Stapelunterlauf von der Ausführung der vorangegangenen Aufgabe eine Größe des gesicherten Bereichs von Stapelspeicher überschreitet.
Verfahren nach Anspruch 6, wobei das Wiederherstellen eines gesicherten Bereichs von einem Stapelspeicher das rekursive Schätzen von Ausgang und Zuständen von Aufgaben mit niedrigeren Speicheradressen in dem Stapelspeicher umfasst, falls der Betrag an Stapelüberlauf von der Ausübung der vorangegangenen Aufgabe die Größe des gesicherten Bereichs von Stapelspeicher überschreitet.
Verfahren nach Anspruch 7, wobei die Größe des gesicherten Bereichs an Stapelspeicher für die zukünftige Ausführung der Softwareanwendung gesteigert wird, falls der Betrag von Stapelüberlauf von der Ausführung der vorangegangenen Aufgabe die Größe des gesicherten Bereichs des Stapelspeichers überschreitet.
Verfahren nach Anspruch 6, wobei das Wiederherstellen eines gesicherten Bereichs des Stapelspeichers das rekursive Schätzen von Ausgang und Zuständen der Aufgaben mit höheren Speicheradressen in dem Stapelspeicher beinhaltet, falls der Betrag von Stapelunterlauf von der Ausführung der vorangegangenen Aufgabe die Größe des gesicherten Bereichs des Stapelspeichers überschreitet.
Verfahren nach Anspruch 1, des Weiteren umfassend das Speichern von Parameterdaten für die vorangegangene Aufgabe, falls der Stapelüberlauf- oder Stapelunterlauffehler während der Ausführung der vorangegangenen Aufgabe aufgetreten ist.