DE112011103505T5

DE112011103505T5 - Verfahren zum Validieren von Laufzeitreferenzen

Info

Publication number: DE112011103505T5
Application number: DE112011103505T
Authority: DE
Inventors: Andrew Wright; Philip Robert Lee; Peggy Anne Deval; Edward Alan Addison
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2010-12-16
Filing date: 2011-10-25
Publication date: 2013-12-05
Also published as: GB201311746D0; CN103250136A; GB2500349A; CN103250136B; US8739136B2; US20120159457A1; WO2012079818A1

Abstract

Ein Verfahren, eine Vorrichtung und ein Computerprogramm zum Identifizieren von in Konflikt stehenden deklarierten ungültigen Laufzeitreferenzen von überlagerten Datenstrukturen eines gemeinsam genutzten Speicherbereichs, wie in einer Programmauflistung deklariert, wobei das Verfahren die Schritte aufweist: in Reaktion auf das Identifizieren einer ersten Datenstruktur und einer Parameterliste in einer Programmauflistung das Identifizieren eines ersten Routineaufrufs und eines sequenziellen Ausführungsablaufs des ersten Routineaufrufs durch die Programmauflistung, um Daten in den gemeinsam genutzten Speicherbereich zu schreiben; in Reaktion auf das Identifizieren einer zweiten Datenstruktur und einer zweiten Parameterliste in der Programmauflistung das Identifizieren eines zweiten Routineaufrufs und eines sequenziellen Ausführungsablaufs des zweiten Routineaufrufs durch die Programmauflistung, um Daten in den gemeinsam genutzten Speicherbereich zu schreiben; und Ermitteln, ob der zweite Routineaufruf versucht, Daten des ersten Routineaufrufs mit den Daten des zweiten Routineaufrufs in dem gemeinsam genutzten Speicherbereich zu überschreiben.

Description

Gebiet der Erfindung
Die Erfindung betrifft das Gebiet der Anwendungsprogrammierung. Insbesondere betrifft die vorliegende Erfindung ein Verfahren und System zum Validieren von Laufzeitreferenzen.
Hintergrund der Erfindung
Große und komplexe Systeme wie das Transaktionsverarbeitungssystem CICS von IBM setzen sich aus vielen Tausenden separater und einzelner Programme zusammen. Jedes Programm weist Quellcode auf, und der Quellcode stellt einen gewissen Typ von Funktionalität oder Dienst bereit. Um diese Funktionalität zu nutzen, tätigt ein Programm einen „Aufruf”, ruft eine Funktion auf, sendet eine Nachricht oder ruft Verfahren zu anderen Klassen (in einer objektorientierten Sprache) in dem oder für das Programm auf, das verwendet werden soll.
In gewissen Typen von Anwendungen sind Programme in Domänen gruppiert. Eine Domäne ist eine Sammlung von Programmen, die so gestaltet sind, dass sie eine bestimmte Funktion bereitstellen, wie zum Beispiel Speicherverwaltung oder Sperren. Eine Domäne ist einer Klasse in objektorientierten Sprachen ähnlich. Jede Domäne stellt ein Gatter bereit, das anderen Domänen das Aufrufen ihrer Dienste gestattet.
Damit ein Programm einen Aufruf an ein anderes Programm tätigen kann, weist ein Programm Deklarationen (Verweise) auf Datenstrukturen und Parameterlisten auf, die verwendet werden, um Gatter in einer anderen Domäne aufzurufen. Parameterlisten werden üblicherweise innerhalb eines Abschnitts in der Nähe des Starts eines Programms deklariert und definieren die verschiedenen Felder für Parametertypen, Optionen, Antwort- und Ursachencodes usw., die dem Code gestatten, zur Laufzeit einen Aufruf an andere Domänen zu tätigen. Diese Deklarationen weisen den Parameterlisten-Speicherbereich auf, der zur Laufzeit vor dem Tätigen eines Aufrufs an eine andere Domäne eingerichtet wird und bei der Rückgabe von einem Domänenaufruf mit den verschiedenen Antwort- und Ursachencodes von einer aufgerufenen Routine innerhalb eines Programms aufgefüllt wird.
Oft werden Programme als „mit Einzelthread” bezeichnet, was bedeutet, dass nur ein einziger Steuer-Thread vorhanden ist, der jeweils durch ein Programm läuft. Dies bedeutet auch, dass zu einem gegebenen Zeitpunkt nur ein Parameterspeichersatz verwendet wird, um den Aufruf an eine andere Domäne zu bearbeiten.
Es ist allgemein übliche Praxis, verschiedene Parameterlistenbereiche als einander überlagernd zu deklarieren. In einer Programmiersprache wie zum Beispiel PLX wird dies erreicht, indem die Parameterlisten als eine „Vereinigungsmenge” von Datenstrukturen definiert werden, wobei alle zu demselben Startpunkt innerhalb des Arbeitsspeichers eines Programms zugeordnet werden. Die „Vereinigungsmenge” wird als die maximale Speichergröße für den größten aller Parameterlistenbereiche deklariert. Der Vorteil dieses Ansatzes ist, dass er die Zuordnung des Arbeitsspeichers eines Programms vereinfacht und den Bedarf an größeren Programmstapelbereichen verringert.
Die separate Deklarierung des Parameterlistenbereichs jeder Domäne bedeutet, dass jede einzelne einem separaten Bereich von Computerspeicher zugeordnet wird, wenn das Programm ausgeführt wird. Dies führt zu einem größeren Programmstapelbereich und einer Zunahme der Speicherbelegung. Eine Überlagerung der Parameterlistenbereiche vermeidet diese unnötige zusätzliche Speicheranforderung durch die Wiederverwendung desselben Bereichs im Speicher für jede der Parameterlisten.
Überlagerte Parameterlisten sind ein effizienter Ansatz für eine bessere Speichernutzung innerhalb einer Programmierumgebung. Allerdings kann ein Problem auftreten, wenn überlagerte Parameterlisten verwendet werden und nicht sichergestellt wird, dass ihr Referenzbereich innerhalb des Quellcodes korrekt verwaltet wird.
Angenommen wird der Fall, in dem ein Programm einen Aufruf an „Domäne 1” tätigt. Das Programm richtet die Parameter in einer Parameterliste ein, um „Domäne 1” in einem gemeinsam genutzten Speicherbereich aufzurufen, und ruft „Domäne 1” auf. Wenn „Domäne 1” ihren Zweck erfüllt hat, kehrt der Steuerungsablauf des gesamten Programms von „Domäne 1” zum Programm zurück. In das Programm ist eine Logik eingebettet, die Felder wie beispielsweise Antwort- und Ursachencodes aus „Domäne 1”, die in dem Parameterlistenbereich eingerichtet worden sind, prüfen und Laufzeitentscheidungen auf der Grundlage der Ergebnisse des Aufrufs treffen kann.
Es gibt jedoch keine Einschränkung für das Programm, einen weiteren Aufruf (an „Domäne 2”) vor dem Prüfen der Ergebnisse aus dem Aufrufen von „Domäne 1” zu tätigen. Das Programm richtet die Parameter ein, um „Domäne 2” in dem gemeinsam genutzten Speicherbereich aufzurufen. Danach ruft das Programm „Domäne 2” auf. Wenn der Steuerungsablauf des Programms von „Domäne 2” zum Programm zurückkehrt, kann die Logik jetzt Felder innerhalb des Parameterlistenbereichs wie vorher prüfen und Laufzeitentscheidungen auf der Grundlage der Ergebnisse des Aufrufs treffen. Die Programmlogik prüft die Ergebnisse des Aufrufs an „Domäne 2”, da die Ergebnisse jetzt in dem gemeinsam genutzten Speicherbereich enthalten sind. Die Programmlogik kann jedoch in einem anderen Szenario entscheiden, die Ergebnisse des früheren Aufrufs an „Domäne 1” zu überprüfen. Da diese Informationen jedoch nicht mehr in dem Parameterlistenbereich des Speichers enthalten sind (weil sie von den Ergebnissen von „Domäne 2” überschrieben worden sind), prüft die Programmlogik Felder innerhalb der Parameter, die im Gegensatz zu „Domäne 1” für „Domäne 2” eingerichtet oder von dieser zurückgegeben wurden. Dies kann zu Logikfehlern während der Laufzeit führen, weil der gemeinsam genutzte Speicherbereich nicht die korrekten Informationen enthält.
Daher besteht beim Stand der Technik ein Bedarf, das oben genannte Problem zu entschärfen.
Kurzdarstellung der Erfindung
Von einem ersten Aspekt aus betrachtet stellt die vorliegende Erfindung ein Verfahren zum Identifizieren von in Konflikt stehenden deklarierten ungültigen Laufzeitreferenzen von überlagerten Datenstrukturen eines gemeinsam genutzten Speicherbereichs bereit, wie er in einer Programmauflistung deklariert ist, wobei das Verfahren die Schritte aufweist: in Reaktion auf das Identifizieren einer ersten Parameterdeklaration einer Parameterliste in einer Programmauflistung das Identifizieren eines ersten Laufzeitaufrufs und eines sequenziellen Ausführungsablaufs des ersten Laufzeitaufrufs durch die Programmauflistung, um Daten in den gemeinsam genutzten Speicherbereich zu schreiben; in Reaktion auf das Identifizieren einer zweiten Parameterdeklaration einer zweiten Parameterliste in der Programmauflistung das Identifizieren eines zweiten Laufzeitaufrufs und eines sequenziellen Ausführungsablaufs des zweiten Laufzeitaufrufs durch die Programmauflistung, um Daten in den gemeinsam genutzten Speicherbereich zu schreiben; das Analysieren des identifizierten sequenziellen Ausführungsablaufs der ersten und zweiten Laufzeitaufrufe, wenn jeder der ersten und zweiten Routineaufrufe Zugriff auf eine Domäne anfordert, und Erzeugen eines Metadatenzustands der ersten und zweiten Laufzeitaufrufe; und Analysieren des Metadatenzustands zum Ermitteln, ob ein Metadatenzustand des ersten Laufzeitaufrufs mit dem Metadatenzustand des zweiten Laufzeitaufrufs in Konflikt steht.
Vorzugsweise stellt die vorliegende Erfindung ein Verfahren bereit, wobei die Domäne eine Ressource aufweist, auf die der Laufzeitaufruf Zugriff anfordert.
Vorzugsweise stellt die vorliegende Erfindung ein Verfahren bereit, wobei der Schritt des Analysierens der Metadaten ferner das Zugreifen auf eine Regelgruppe aufweist, die die Wichtigkeit eines Laufzeitaufrufs innerhalb des identifizierten Ausführungsablaufs ermittelt.
Vorzugsweise stellt die vorliegende Erfindung ein Verfahren bereit, das ferner das Erzeugen von historischen Regeldaten aus dem erzeugten Metadatenzustand aufweist.
Vorzugsweise stellt die vorliegende Erfindung ein Verfahren bereit, das ferner das Speichern der historischen Regeldaten in einem Datenspeicher und das Aktualisieren der analysierenden Komponente mit den historischen Regeldaten aufweist.
Vorzugsweise stellt die vorliegende Erfindung ein Verfahren bereit, das ferner das Identifizieren aus einer der Parameterlisten aufweist, ob eine Sperrdomäne, Ressourcendomäne oder Speicherdomäne angefordert worden ist.
Vorzugsweise stellt die vorliegende Erfindung ein Verfahren bereit, das ferner in Reaktion darauf, dass eine Sperrdomäne, Ressourcendomäne oder Speicherdomäne identifiziert wurde, einen Antwort- und einen Ursachencode in dem Metadatenzustand des gemeinsam genutzten Speicherbereichs des Programms auffüllt.
Vorzugsweise stellt die vorliegende Erfindung ein Verfahren bereit, das ferner das Analysieren der aufgefüllten Antwort- und Ursachencodes aufweist, um einen oder mehrere ungültige verschachtelte Aufrufe an den gemeinsam genutzten Speicherbereich des Programms zu identifizieren.
Vorzugsweise stellt die vorliegende Erfindung ein Verfahren bereit, das ferner das Erzeugen einer Nachricht aufweist, die den einen oder mehrere ermittelte Konflikte für das Übertragen einer integrierten Entwicklungsumgebung eines Diagnosetools an einen Compiler aufweist.
Von einem weiteren Aspekt aus betrachtet stellt die vorliegende Erfindung eine Vorrichtung zum Identifizieren von in Konflikt stehenden deklarierten ungültigen Laufzeitreferenzen von überlagerten Datenstrukturen eines gemeinsam genutzten Speicherbereichs bereit, wie in einer Programmauflistung deklariert, wobei die Vorrichtung die Schritte aufweist: in Reaktion auf das Identifizieren einer ersten Parameterdeklaration einer Parameterliste in einer Programmauflistung eine Parsing-Komponente zum Identifizieren eines ersten Laufzeitaufrufs und eines sequenziellen Ausführungsablaufs des ersten Laufzeitaufrufs durch die Programmauflistung, um Daten in den gemeinsam genutzten Speicherbereich zu schreiben; in Reaktion auf das Identifizieren einer zweiten Parameterdeklaration einer zweiten Parameterliste in der Programmauflistung eine Parsing-Komponente zum Identifizieren eines zweiten Laufzeitaufrufs und eines sequenziellen Ausführungsablaufs des zweiten Laufzeitaufrufs durch die Programmauflistung, um Daten in den gemeinsam genutzten Speicherbereich zu schreiben; eine analysierende Komponente zum Analysieren des identifizierten sequenziellen Ausführungsablaufs der ersten und zweiten Laufzeitaufrufe, wenn jeder der ersten und zweiten Routineaufrufe Zugriff auf eine Domäne anfordert, und eine zuordnende Komponente zum Erzeugen eines Metadatenzustands der ersten und zweiten Laufzeitaufrufe; und eine Analysenkomponente zum Analysieren des Metadatenzustands zum Ermitteln, ob ein Metadatenzustand des ersten Laufzeitaufrufs mit dem Metadatenzustand des zweiten Laufzeitaufrufs in Konflikt steht.
Vorzugsweise stellt die vorliegende Erfindung eine Vorrichtung bereit, wobei die Domäne eine Ressource aufweist, auf die der Laufzeitaufruf Zugriff anfordert.
Vorzugsweise stellt die vorliegende Erfindung eine Vorrichtung bereit, wobei der Schritt des Analysierens der Metadaten ferner das Zugreifen auf eine Regelgruppe aufweist, die die Wichtigkeit eines Laufzeitaufrufs innerhalb des identifizierten Ausführungsablaufs ermittelt.
Vorzugsweise stellt die vorliegende Erfindung eine Vorrichtung bereit, die ferner eine historische Komponente zum Erzeugen von historischen Regeldaten aus dem erzeugten Metadatenzustand aufweist.
Vorzugsweise stellt die vorliegende Erfindung eine Vorrichtung bereit, die ferner eine historische Komponente zum Speichern der historischen Regeldaten in einem Datenspeicher und Aktualisieren der analysierenden Komponente mit den historischen Regeldaten aufweist.
Vorzugsweise stellt die vorliegende Erfindung eine Vorrichtung bereit, die ferner eine Analysekomponente zum Identifizieren aus einer der Parameterlisten aufweist, ob eine Sperrdomäne, Ressourcendomäne oder Speicherdomäne angefordert worden ist.
Vorzugsweise stellt die vorliegende Erfindung eine Vorrichtung bereit, die ferner in Reaktion darauf, dass eine Sperrdomäne, Ressourcendomäne oder Speicherdomäne identifiziert wurde, eine zuordnende Komponente zum Auffüllen eines Antwort- und eines Ursachencodes in dem Metadatenzustand des gemeinsam genutzten Speicherbereichs des Programms aufweist.
Vorzugsweise stellt die vorliegende Erfindung eine Vorrichtung bereit, die ferner eine Analysekomponente aufweist, die die aufgefüllten Antwort- und Ursachencodes analysiert, um einen oder mehrere ungültige verschachtelte Aufrufe an den gemeinsam genutzten Speicherbereich des Programms zu identifizieren.
Vorzugsweise stellt die vorliegende Erfindung eine Vorrichtung bereit, die ferner eine darstellende Komponente zum Erzeugen einer Nachricht aufweist, die den einen oder mehrere ermittelte Konflikte für das Übertragen einer integrierten Entwicklungsumgebung eines Diagnosetools an einen Compiler aufweist.
Von einem weiteren Aspekt aus betrachtet stellt die vorliegende Erfindung ein Verfahren zum Identifizieren von in Konflikt stehenden deklarierten ungültigen Laufzeitreferenzen von überlagerten Datenstrukturen eines gemeinsam genutzten Speicherbereichs bereit, wie in einer Programmauflistung deklariert, wobei das Verfahren die Schritte aufweist: in Reaktion auf das Identifizieren einer ersten Datenstruktur und einer Parameterliste in einer Programmauflistung das Identifizieren eines ersten Routineaufrufs und eines sequenziellen Ausführungsablaufs des ersten Routineaufrufs durch die Programmauflistung, um Daten in den gemeinsam genutzten Speicherbereich zu schreiben; in Reaktion auf das Identifizieren einer zweiten Datenstruktur und einer zweiten Parameterliste in der Programmauflistung das Identifizieren eines zweiten Routineaufrufs und eines sequenziellen Ausführungsablaufs des zweiten Routineaufrufs durch die Programmauflistung, um Daten in den gemeinsam genutzten Speicherbereich zu schreiben; und Ermitteln, ob der zweite Routineaufruf versucht, Daten des ersten Routineaufrufs mit den Daten des zweiten Routineaufrufs in dem gemeinsam genutzten Speicherbereich zu überschreiben.
Von einem weiteren Aspekt aus betrachtet stellt die vorliegende Erfindung ein Computerprogramm bereit, das Computerprogrammcode aufweist, um, wenn er in ein Computersystem geladen und ausgeführt wird, alle Schritte des Verfahrens wie oben beschrieben auszuführen.
Kurzbeschreibung der Zeichnungen
Im Folgenden wird eine bevorzugte Ausführungsform der vorliegenden Erfindung allein zu Beispielzwecken unter Bezugnahme auf die begleitenden Zeichnungen beschrieben, wobei:
1 ein Datenverarbeitungssystem des Stands der Technik ist, in dem eine bevorzugte Ausführungsform der vorliegenden Erfindung umgesetzt werden kann;
2 ein Blockschaubild ist, das eine Validierungskomponente darstellt, die gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung eine Schnittstelle mit einer Compileranwendung, einer integrierten Entwicklungsumgebung oder einem Editor bildet;
3 ein Blockschaubild ist, das gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung eine Programmauflistung veranschaulicht, die eine Vielzahl von Programmen aufweist;
4 ein Blockschaubild ist, das eine aus dem Stand der Technik bekannte Parameterauflistung veranschaulicht;
5 ein Blockschaubild ist, das die Unterkomponenten der Validierungskomponente von 2 gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung veranschaulicht; und
6 und 7 ein Ablaufplan sind, der die Prozessschritte der Validierungskomponente gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung veranschaulicht.
Ausführliche Beschreibung der Erfindung
Das Datenverarbeitungssystem 100 weist eine zentrale Verarbeitungseinheit 101 mit einem primären Speicher in der Form des Speichers 102 (RAM und ROM) auf. Der Speicher 102 speichert Anwendungsinformationen und Daten, nach denen Anwendungen handeln oder die von Anwendungen erstellt werden. Die Informationen enthalten den Betriebssystemcode für das Datenverarbeitungssystem 100 und Anwendungscode für Anwendungen, die auf dem Computersystem 100 ausgeführt werden. Ein sekundärer Speicher enthält einen optischen Plattenspeicher 103 und einen Magnetplattenspeicher 104. Daten und Anwendungsinformationen können auch auf dem sekundären Speicher gespeichert werden und von dort abgerufen werden.
Das Datenverarbeitungssystem 100 enthält ein Netzwerkverbindungsmittel 105 zum Bilden einer Schnittstelle zwischen dem Datenverarbeitungssystem 100 und einem Netzwerk. Das Datenverarbeitungssystem 100 kann auch andere externe Quellen-Datenübertragungsmittel haben wie beispielsweise eine Faxmodem- oder Telefonverbindung.
Die zentrale Verarbeitungseinheit 101 weist Eingabemöglichkeiten in der Form von beispielsweise einer Tastatur 106, einer Maus 107, einer Spracheingabe 108 und eines Scanners 109 zum Eingeben von Text, Bildern, Grafik oder dergleichen auf. Ausgabemöglichkeiten aus der zentralen Verarbeitungseinheit 101 können ein Anzeigemittel 110, einen Drucker 111, eine Tonausgabe 112, eine Videoausgabe 113 usw. enthalten.
Unter Bezugnahme auf 2 und gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung wird eine Validierungskomponente 215 zum Validieren von Laufzeitreferenzen veranschaulicht. Die Validierungskomponente 215 ist betriebsfähig zum Bilden einer Schnittstelle mit einer Compileranwendung 200, einer Editoranwendung 205 und/oder einer integrierten Entwicklungsumgebung (IDE) 210. Die Validierungskomponente 215 ist in einer bevorzugten Ausführungsform eine Plug-In-Anwendung, die mit einem Compiler 200, einem Editor 205 oder einer IDE 210 betriebsfähig ist. Alternativ kann die Validierungskomponente 215 der vorliegenden Erfindung in einen Compiler 200, einen Editor 205 oder eine IDE 210 integriert sein.
Die Validierungskomponente 215 kann entweder durch einen Befehl in der Editoranwendung 205, der Compileranwendung 200 oder in der IDE 210 initiiert werden. Um der Klarheit willen werden diese Komponenten als „initiierende Anwendung” bezeichnet.
Die Validierungskomponente 215 wird ausgelöst, indem sie eine Anforderung zum Analysieren von Auflistungen von Quellcode oder kompiliertem Code (Programmauflistungen) von irgendeiner der initiierenden Anwendungen empfängt.
Ein Fachmann wird verstehen, dass eine Programmauflistung Quellcode, der in einer spezifischen Programmiersprache geschrieben ist, Objektcode, der durch den Compiler aus dem Quellcode (aber vor dem Binden) erzeugt wird, aufweisen kann und typischerweise eine oder mehrere Datenstrukturen aufweist, die Felder aufweisen, auf die durch den Programmquellcode verwiesen wird.
Ein Fachmann wird ebenfalls erkennen, dass die Programmauflistung auch nur den Quellcode oder eine beliebige Kombination des Vorgenannten aufweisen kann.
Unter Bezugnahme auf 3 und 4 wird eine Programmauflistung 300 veranschaulicht. Die Programmauflistung weist Aufrufe und eine Deklaration auf, die einer Vielzahl von Programmen zugehörig sind, und zwar „Programm A” 305, „Programm B” 310 und „Programm C” 315. Alle der Programme 305, 310, 315 arbeiten zusammen, um die Funktionalität einer Anwendung 335 bereitzustellen. Die Anwendung 335 weist eine Programmlogik 330 auf, die eine Routine befähigt, ausgeführt zu werden und andere Programme, um in einer bestimmten Reihenfolge aufgerufen zu werden. Zum Beispiel kann die Programmlogik 330 vorgeben, dass das „Programm A” 305 zuerst ausgeführt wird, gefolgt von „Programm B” 310 und „Programm C” 315. Ein Fachmann wird jedoch erkennen, dass jede Ausführungsreihenfolge der Programme 305, 310, 315 abhängig von der Funktionalität möglich ist, die für die Anwendung erforderlich ist.
Die Anwendung 335 weist eine Anzahl von Deklarationen 320 auf, und innerhalb dieser Deklarationen werden Parameterlisten während der Laufzeit deklariert und eingerichtet, bevor ein Aufruf an ein anderes Programm 305, 310, 315 getätigt wird. 4 veranschaulicht ein Beispiel einer Vereinigungsmenge von Parameterlisten 400.
Ein überlagerter Speicherabschnitt (gemeinsam genutzter Speicher) wird mit der Bezeichnung „xxyy_parms” 405 deklariert. Innerhalb dieser Deklaration befindet sich eine Vereinigungsmenge von 5 Parameterlisten 410, die wiedergeben, dass die Anwendung 335, die diese Deklarationen enthält, 5 verschiedene Domänenaufrufe nutzen kann. Beispiele für Parameterlisten sind „apex_parms”, „lmlm_parms”, „meme_parms” usw. Jede dieser Parameterlisten weist Antwort- und Ursachenfelder 325 wie beispielsweise „apex_response”, „apex_reason”, „lmlm_response”, „lmlm_reason”, „meme_response”, „meme_reason” usw. zum Prüfen verschiedener Antworten auf, um gewisse Laufzeitentscheidungen zu treffen.
Die Validierung wird ausgeführt, um Instanzen zu validieren, in denen Referenzen auf Datenstrukturen in vereinigten Speicherbereichen vorgenommen werden, nachdem die Inhalte der vereinigten Speicherbereiche durch einen verschachtelten Aufruf an ein anderes Programm unter Verwendung desselben Parameterlistenbereichs innerhalb des Stapelbereichs des Arbeitsspeichers des Programms ungültig gemacht wurden.
Angenommen wird das folgende Szenario, das sich auf verschachtelte Programmaufrufe an eine Sperrdomäne und eine Speicherdomäne bezieht, die dem Aufrufen des „Programms A” 305, des „Programms B” 310 oder des „Programms C” gleichen. Wenn eine Anwendung 335 sich einigen Speicher von der Speicherdomäne verschaffen muss, was (in Datenverarbeitungsbegriffen) eine beträchtliche Zeitmenge in Anspruch nehmen kann, kann die Anwendung 335 eine Ressourcensperre während des Aufrufs nicht aufrechterhalten, weil dies schwerwiegende Auswirkungen auf die Systemleistung haben könnte. Daher ruft die Programmlogik die Sperrdomäne auf, um die Sperre aufzuheben (sie richtet die „lmlm_parms” ein und nimmt den Aufruf vor). Die Sperrdomäne füllt die Antwort- und Ursachencodes in dem Parameterlistenbereich 400 auf, der zur Überprüfung durch die aufrufende Anwendung 335 bereit ist.
Die Programmlogik 330 prüft die Ergebnisse des Aufrufs an die Sperrdomäne. Im Erfolgsfall ruft die Programmlogik 330 die Speicherdomäne auf, um sich den Speicher zu verschaffen. Die Programmlogik 330 richtet die „smmc_parms” ein und nimmt den Aufruf vor. Die Speicherdomäne verschafft sich den Speicher und füllt die Antwort- und Ursachencodes 325 in dem Parameterlistenbereich 400 auf, der zur Überprüfung durch die aufrufende Anwendung 335 bereit ist.
Die Programmlogik 330 muss sich die Ressourcensperre wieder verschaffen, die sie für den Aufruf freigeben musste, um sich den Speicher zu verschaffen. Sie richtet die „lmlm_parms” ein und ruft dann die Sperrdomäne auf. Die Sperrdomäne verschafft sich die Sperre wieder und füllt die Antwort- und Ursachencodes in dem Parameterlistenbereich auf, der zur Überprüfung durch das aufrufende Programm bereit ist. Dabei werden die „smmc_parms” überlagert, und die Daten sind jetzt verloren. Dies trifft auch auf die Antwort- und Ursachencodes aus dem Speicherdomänenaufruf zu.
Nach der Rückgabe der Steuerung an die Anwendung 335 prüft die Programmlogik 330 jetzt die Antwort- und Ursachencodes 325 aus der Speicherdomäne. Diese Informationen sind jedoch verloren gegangen, da der Parameterlistenspeicher durch den Aufruf an die Sperrdomäne wiederverwendet worden ist. Jetzt können unvorhersehbare Laufzeitergebnisse auftreten, weil die Speicherbereiche und das Programmverhalten nicht mehr definiert sind.
Um dieses Problem gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung zu erkennen und zu vermeiden, erkennt die Validierungskomponente 215 die Laufzeitreferenzen und validiert sie, um zu ermitteln, ob ein Fehler im Ablauf der Programmlogik 330 vorliegt, wie beispielsweise, ob der Bereich des gemeinsam genutzten Speicher mit falschen Speicherreferenzen überlagert ist. Die Validierungskomponente 215 weist eine Anzahl von Unterkomponenten auf. Diese sind eine empfangende Komponente 500, eine Parsing-Komponente 505, eine zuordnende Komponente 510, eine Analysekomponente 530, eine darstellende Komponente 515, eine historische Komponente 520 und ein Metadaten-Speicherbereich 525.
Der Prozess, durch den die Unterkomponenten der Validierungskomponente 215 gemäß einer bevorzugten Ausführungsform der Erfindung zusammenarbeiten, wird im Folgenden als Beispiel und unter Bezugnahme auf die 5, 6 und 7 dargestellt.
Die empfangende Komponente 500 empfängt eine Programmauflistung 300 von der Anwendung. Die empfangende Komponente 500 überträgt die empfangene Programmauflistung zur weiteren Verarbeitung (Schritt 600) an die Parsing-Komponente 505.
Die Parsing-Komponente 505 durchsucht die Programmauflistung, um eine oder mehrere Parameterdeklarationen zu identifizieren, die als sich überlagernd identifiziert wurden, und identifiziert auch jeden der Laufzeitaufrufe in der Programmauflistung, die auf jedes der Datenfelder in den Parameterlisten verweisen. Die Parsing-Komponente 505 überträgt die identifizierten Parameterdeklarationen und jedes der identifizierten Datenfelder zur weiteren Verarbeitung (Schritt 605) an die zuordnende Komponente 510.
Die zuordnende Komponente 510 analysiert die empfangenen Daten und ordnet jeden der identifizierten Aufrufe und deren sequenziellen Ausführungsablauf innerhalb des Quellcodes als Metadatenzustand zu. Die Metadaten werden in einem Metadatenspeicher 525 gespeichert. Die zuordnende Komponente 510 ordnet auch die Referenzen auf die Parameterlistenfelder als Metadaten zu (Schritt 610). In dem Beispiel von 4 würde die folgende Zuordnung stattfinden, wenn der Programmlogikablauf geparst und an die zuordnende Komponente 510 übergeben worden ist.
In dem vorher angegebenen Beispiel bemerkt die Programmlogik, dass der Parameterlistenspeicher aktuell „in Gebrauch” ist aufgrund der Tatsache, dass ein Aufruf an eine Sperrdomäne angefordert wurde, wenn die Programmlogik die Parameterliste für den Aufruf an die Sperrdomäne einrichtet und den Aufruf ausgibt.
Jedes Mal, wenn die Programmlogik identifiziert, dass ein Aufruf an eine Domäne „in Gebrauch” ist, wird dies als ein Metadatenzustand eingerichtet, ein Beispiel (Beispiel 1) dafür ist wie folgt: Beispiel 1
Die Metadaten können auch andere Daten aufweisen, die die Daten mit den vorgenannten Zustandsübergängen zu bestimmten Quellcodezeilen in der Programmauflistung und zu ihrem Ausführungspunkt innerhalb der Programmlogik zuordnen, wie beispielsweise innerhalb einer aufgerufenen Unterroutine oder Funktion.
Die Programmauflistung 300 wird weiterhin geparst. Die zuordnende Komponente 510 bemerkt, dass der Parameterlistenspeicher nicht mehr von Interesse ist aufgrund der Tatsache, dass die Antwort- und Ursachenfelder der Sperrdomäne geprüft und daraus resultierende Codepfade definiert worden sind. Die Programmlogik überprüft die Antwort- und Ursachencodes aus der Sperrdomäne und verlässt das Programm, wenn ein Fehler aufgetreten ist, wie folgt (Beispiel 2): Beispiel 2
Die Programmauflistung wird weiterhin geparst. Die Programmlogik ruft die Speicherdomäne auf, um sich den Speicher zu verschaffen. Sie richtet die „smmc_parms” eine und nimmt den Aufruf vor. Die Speicherdomäne verschafft sich den Speicher und füllt ihre Antwort- und Ursachencodes in dem Parameterlistenbereich auf, der zur Überprüfung durch das aufrufende Programm bereit ist.
Die zuordnende Komponente 510 stellt dies durch das Aktualisieren ihrer Metadaten für den Zustand des gemeinsam genutzten Parameterlistenspeichers des Programms und ihren Aufruf an die Speicherdomäne dar wie folgt (Beispiel 3): Beispiel 3
Die Programmlogik 330 muss sich jetzt die Ressourcensperre wieder verschaffen, sie richtet daher die Parameterinformationen „lmlm_parms” ein und nimmt den Aufruf an die Sperrdomäne vor. Das erneute Verschaffen der Sperre wird ausgeführt, und die Sperrdomäne füllt die Antwort- und Ursachencodes in dem Parameterlistenbereich auf, der zur Überprüfung durch die aufrufende Anwendung 330 bereit ist.
Dabei werden die „smmc_parms” überlagert, und die Daten sind jetzt verloren. Dies trifft auch auf die Antwort- und Ursachencodes aus dem Speicherdomänenaufruf zu.
Die zuordnende Komponente 510 stellt dies durch das Aktualisieren ihrer Metadaten für den Zustand des gemeinsam genutzten Parameterlistenspeichers des Programms und den Aufruf an die Sperrdomäne dar wie folgt (Beispiel 4): Beispiel 4
Die Programmlogik 330 kann jetzt irrtümlicherweise die Antwort- und Ursachencodes aus dem vorher vorgenommenen Speicherdomänenaufruf überprüfen. Diese Informationen sind jedoch verloren gegangen, da der Parameterlistenspeicher durch den Aufruf an die Sperrdomäne wiederverwendet worden ist. Wenn die Anweisungen, die die Felder smmc_parm prüfen, durch die Erfindung geparst werden, zeichnet die zuordnende Komponente 510 die Tatsache jetzt wie folgt auf (Beispiel 5): Beispiel 5
Der Rest der Programmlogik 330 wird geparst, und zusätzliche Metadaten werden von der zuordnenden Komponente 510 erstellt, um die sonstige Verwendung von Domänenaufrufen und deren Parameterlisteninhalten durch die Anwendung soweit zutreffend wiederzugeben.
Wenn die gesamte Programmauflistung geparst worden ist, übergibt die zuordnende Komponente 510 nach dem Abschließen der Zuordnung und Erstellen der Metadaten die Steuerung an die Analysekomponente 530.
Die Analysekomponente 530 greift auf die Metadaten zu und analysiert die Metadaten, die durch die Zuordnung der Programmauflistung 300 erstellt worden sind. Die Analysekomponente 530 ermittelt, welche Aufrufe ungültig auf Parameterlistenfelder verwiesen haben, die nicht mehr innerhalb ihres spezifischen Bereichs lagen (Schritt 615), indem sie auf die Programmlogik und den Status eines Aufrufs verweisen, wie durch die Metadaten beschrieben.
Anhand der vorgenannten Beispiele 1 bis 5 kann die Analysekomponente feststellen, dass die Anwendung auf den Inhalt von „smmc_parms” verwiesen hat, nachdem der gemeinsam genutzte Parameterlistenbereich durch einen verschachtelten Aufruf an die Sperrdomäne erneut verwendet worden ist.
Die Analysekomponente 530 ermittelt dies durch Analysieren der Metadaten, die den Ablauf von Ereignissen in der Programmlogik beschreiben, und der verschiedenen Zustandsmarkierungen (boolesch oder sonstige), die beim Parsen der Anwendung eingerichtet wurden. In dem vorgenannten Beispiel können dazu die Markierungen „smmc_parms_in_scope” gehören, die auf „falsch” (false) gesetzt sind, und „invalid_reference_to_smmc_parms”, die auf „wahr” (true) gesetzt sind. Dies würde bestätigen, dass auf den gemeinsam genutzten Speicher verwiesen worden ist, der die „smmc_parms”-Informationen nicht mehr enthielt. Der Inhalt der booleschen Einstellungen „lmlm_parms_in_scope” und „lock_domain_being_called” bestätigt den Typ eines verschachtelten Aufrufs, der den Inhalt des gemeinsam genutzten Parameterlistenspeichers ungültig gemacht hat.
Die Metadaten weisen auch begleitende Daten auf, die die Anweisungsnummer der Quellenanweisungen in der Programmauflistung und deren Ausführungsreihenfolge im Steuerungsablauf des Programms wiedergeben. Die Analysekomponente 530 analysiert diese Informationen, um einen oder mehrere ungültige Aufrufe zu identifizieren, wobei Daten in dem gemeinsam genutzten Speicherbereich überlagert worden sind.
Die Analysekomponente 530 kompiliert eine Ergebnisgruppe und übergibt die Ergebnisgruppe an eine darstellende Komponente 515, die Warnungs- und/oder Fehlermeldungen entsprechend den Problemen erzeugt, die durch die Analysekomponente 530 identifiziert wurden (Schritt 620). Wenn zum Beispiel und unter Bezugnahme auf Beispiel 6 ein ungültiges Verweisen auf die Felder „smmc_response” und „smmc_reason” erkannt wurde, wird die darstellende Komponente 515 darüber zusammen mit dem Anweisungskontext in Bezug auf das Programm selbst benachrichtigt. Ein Beispiel für Nachrichten für ein derartiges Szenario könnte sein: Beispiel 6
Die Meldungen würden ihrem Ausgabeziel entsprechend dargestellt werden, wie beispielsweise eine Zeilenausgabe in einer Editieranzeige oder Compilerliste oder als Diagnose in einem Fenster in einer IDE.
In einer weiteren Ausführungsform greift die Analysekomponente 530 auf historische Metadaten zu, die von einer historischen Komponente 520 zur zukünftigen Verwendung erfasst worden sind (Schritt 700 und 705). Die historische Komponente 520 erfasst kontinuierlich Fehlersituationen, an denen eine Kombination von Programmieraufrufen an andere Programme und Parameterlistenreferenzen beteiligt ist. Eine Fehlersituation ist eine, die von der Analysekomponente 530 identifiziert wird, sobald der zuordnende Prozess abgeschlossen ist (Schritt 710). Die erfassten historischen Daten ermöglichen die Erfassung typischer Fehlersituationen, an denen Kombinationen von Programmieraufrufen und Parameterlistenreferenzen beteiligt sind. Derartige historische Daten können für die Analysekomponente 530 verfügbar sein, wenn Metadaten für zukünftige Programmauflistungen analysiert werden.
Die Analysekomponente 530 kann nach Ähnlichkeiten von derartigen Kombinationen innerhalb der Zustandsübergänge suchen, die durch die unter Analyse stehenden Metadaten wiedergegeben werden, und nach Situationen suchen, in denen solche Fehler potenziell in dem unter Analyse stehenden Programm zu sehen sein könnten, wenn zum Beispiel logische Änderungen vorgenommen wurden, die sich auf den Ablauf von Ereignissen innerhalb der Programmlogik um den Bereich eines Domänenaufrufs auswirken könnten, oder eine Einfügung von bestimmten Anweisungen oder Unterroutine-Aufrufen zwischen einen Domänenaufruf und eine Validierung ihrer Ergebnisse vorgenommen wurde. Die Analysekomponente 530 kann dann davor warnen, indem entsprechende Nachrichtendaten (Schritt 715) erzeugt werden, zum Beispiel wie folgt in einem Fall, in dem Aufrufe zum Sperren und Aufheben einer Sperre für eine Ressource aktuell nicht in dem gerade analysierten Programm vorhanden waren (Beispiel 7): Beispiel 7
„Beachten Sie bitte die Auswirkung einer Hinzufügung von Aufrufen zum Aufheben einer Sperre oder zum Sperren von Ressourcen um diese Operation zum Abrufen von Speicher. Die Parameterlistenbereiche „smmc” und „lmlm” sind in einer Vereinigungsmenge deklariert und überlagern sich daher. Eine Referenz auf die Felder „smmc_response” und „smmc_reason” würde durch das Hinzufügen eines früheren Aufrufs an die Sperrenmanagerkomponente ungültig gemacht, die eine typische auszuführende Operation ist.”
Die Erfindung kann Form einer vollständigen Hardware-Ausführungsform, einer vollständigen Software-Ausführungsform oder einer Ausführungsform annehmen, die Hardware- und Software-Elemente enthält. In einer bevorzugten Ausführungsform ist die Erfindung in einer Software umgesetzt, die Firmware, residente Software, Mikrocode usw. enthält, aber nicht darauf beschränkt ist.
Die Erfindung kann die Form eines Computerprogrammprodukts annehmen, auf das von einem computerverwendbaren oder computerlesbaren Medium aus zugegriffen werden kann, das Programmcode zur Verwendung durch oder in Verbindung mit einem Computer oder irgendeinem Anweisungsausführungssystem bereitstellt. Zum Zweck dieser Beschreibung kann ein computerverwendbares oder computerlesbares Medium jede Vorrichtung sein, das das Programm zur Verwendung durch oder in Verbindung mit einem System, einer Vorrichtung oder einer Einheit zur Anweisungsausführung enthalten, speichern, übertragen, verbreiten oder transportieren kann.
Das Medium kann ein elektronisches, magnetisches, optisches, elektromagnetisches, Infrarot- oder Halbleitersystem (oder eine Vorrichtung oder Einheit) oder ein Verbreitungsmedium sein. Zu Beispielen für ein computerlesbares Medium zählen ein Halbleiter- oder Solid-State-Speicher, ein Magnetband, eine austauschbare Computerdiskette, ein Arbeitsspeicher (RAM), ein Nur-Lese-Speicher (ROM), eine Magnetplatte und eine optische Platte. Zu aktuellen Beispielen für optische Platten zählen ein CD-ROM, eine CD-R/W und eine DVD.
Verbesserungen und Modifizierungen können an dem Vorgenannten vorgenommen werden ohne von dem Schutzumfang der vorliegenden Erfindung abzuweichen.

Claims

Verfahren zum Identifizieren von in Konflikt stehenden deklarierten ungültigen Laufzeitreferenzen von überlagerten Datenstrukturen eines gemeinsam genutzten Speicherbereichs, wie in einer Programmauflistung deklariert, wobei das Verfahren die Schritte aufweist: in Reaktion auf das Identifizieren einer ersten Parameterdeklaration einer Parameterliste in einer Programmauflistung das Identifizieren eines ersten Laufzeitaufrufs und eines sequenziellen Ausführungsablaufs des ersten Laufzeitaufrufs durch die Programmauflistung, um Daten in den gemeinsam genutzten Speicherbereich zu schreiben; in Reaktion auf das Identifizieren einer zweiten Parameterdeklaration einer zweiten Parameterliste in der Programmauflistung das Identifizieren eines zweiten Laufzeitaufrufs und eines sequenziellen Ausführungsablaufs des zweiten Laufzeitaufrufs durch die Programmauflistung, um Daten in den gemeinsam genutzten Speicherbereich zu schreiben; Analysieren des identifizierten sequenziellen Ausführungsablaufs der ersten und zweiten Laufzeitaufrufe, wenn jeder der ersten und zweiten Routineaufrufe Zugriff auf eine Domäne anfordert, und Erzeugen eines Metadatenzustands der ersten und zweiten Laufzeitaufrufe; und Analysieren des Metadatenzustands zum Ermitteln, ob ein Metadatenzustand des ersten Laufzeitaufrufs mit dem Metadatenzustand des zweiten Laufzeitaufrufs in Konflikt steht.
Verfahren nach Anspruch 1, wobei die Domäne eine Ressource aufweist, auf die der Laufzeitaufruf Zugriff anfordert.
Verfahren nach Anspruch 1, wobei der Schritt des Analysierens der Metadaten ferner das Zugreifen auf eine Regelgruppe aufweist, die die Wichtigkeit eines Laufzeitaufrufs innerhalb des identifizierten Ausführungsablaufs ermittelt.
Verfahren nach Anspruch 1, das ferner das Erzeugen von historischen Regeldaten aus dem erzeugten Metadatenzustand aufweist.
Verfahren nach Anspruch 4, das ferner das Speichern der historischen Regeldaten in einem Datenspeicher und das Aktualisieren der analysierenden Komponente mit den historischen Regeldaten aufweist.
Verfahren nach Anspruch 1 oder Anspruch 2, das ferner das Identifizieren aus einer der Parameterlisten aufweist, ob eine Sperrdomäne, Ressourcendomäne oder Speicherdomäne angefordert worden ist.
Verfahren nach Anspruch 6, das ferner in Reaktion darauf, dass eine Sperrdomäne, Ressourcendomäne oder Speicherdomäne identifiziert wurde, einen Antwort- und einen Ursachencode in dem Metadatenzustand des gemeinsam genutzten Speicherbereichs des Programms auffüllt.
Verfahren nach irgendeinem vorhergehenden Anspruch, das ferner das Analysieren der aufgefüllten Antwort- und Ursachencodes aufweist, um einen oder mehrere ungültige verschachtelte Aufrufe an den gemeinsam genutzten Speicherbereich des Programms zu identifizieren.
Verfahren nach Anspruch 1, das ferner das Erzeugen einer Nachricht aufweist, die den einen oder mehrere ermittelte Konflikte zum Senden einer integrierten Entwicklungsumgebung eines Diagnosetools an einen Compiler aufweist.
Vorrichtung zum Identifizieren von in Konflikt stehenden deklarierten ungültigen Laufzeitreferenzen von überlagerten Datenstrukturen eines gemeinsam genutzten Speicherbereichs, wie in einer Programmauflistung deklariert, wobei die Vorrichtung die Schritte aufweist: in Reaktion auf das Identifizieren einer ersten Parameterdeklaration einer Parameterliste in einer Programmauflistung eine Parsing-Komponente zum Identifizieren eines ersten Laufzeitaufrufs und eines sequenziellen Ausführungsablaufs des ersten Laufzeitaufrufs durch die Programmauflistung, um Daten in den gemeinsam genutzten Speicherbereich zu schreiben; in Reaktion auf das Identifizieren einer zweiten Parameterdeklaration einer zweiten Parameterliste in der Programmauflistung eine Parsing-Komponente zum Identifizieren eines zweiten Laufzeitaufrufs und eines sequenziellen Ausführungsablaufs des zweiten Laufzeitaufrufs durch die Programmauflistung, um Daten in den gemeinsam genutzten Speicherbereich zu schreiben; eine analysierende Komponente zum Analysieren des identifizierten sequenziellen Ausführungsablaufs der ersten und zweiten Laufzeitaufrufe, wenn jeder der ersten und zweiten Routineaufrufe Zugriff auf eine Domäne anfordert, und eine zuordnende Komponente zum Erzeugen eines Metadatenzustands der ersten und zweiten Laufzeitaufrufe; und eine Analysenkomponente zum Analysieren des Metadatenzustands zum Ermitteln, ob ein Metadatenzustand des ersten Laufzeitaufrufs mit dem Metadatenzustand des zweiten Laufzeitaufrufs in Konflikt steht.
Vorrichtung nach Anspruch 10, wobei die Domäne eine Ressource aufweist, auf die der Laufzeitaufruf Zugriff anfordert.
Vorrichtung nach Anspruch 10, wobei ein Schritt des Analysierens der Metadaten ferner das Zugreifen auf eine Regelgruppe aufweist, die die Wichtigkeit eines Laufzeitaufrufs innerhalb des identifizierten Ausführungsablaufs ermittelt.
Vorrichtung nach Anspruch 10, die ferner eine historische Komponente zum Erzeugen von historischen Regeldaten aus dem erzeugten Metadatenzustand aufweist.
Vorrichtung nach Anspruch 13, die ferner eine historische Komponente zum Speichern der historischen Regeldaten in einem Datenspeicher und Aktualisieren der analysierenden Komponente mit den historischen Regeldaten aufweist.
Vorrichtung nach Anspruch 10 oder Anspruch 11, die ferner eine Analysekomponente zum Identifizieren aus einer der Parameterlisten aufweist, ob eine Sperrdomäne, Ressourcendomäne oder Speicherdomäne angefordert worden ist.
Vorrichtung nach Anspruch 15, die ferner in Reaktion darauf, dass eine Sperrdomäne, Ressourcendomäne oder Speicherdomäne identifiziert wurde, eine zuordnende Komponente zum Auffüllen eines Antwort- und eines Ursachencodes in dem Metadatenzustand des gemeinsam genutzten Speicherbereichs des Programms aufweist.
Vorrichtung nach irgendeinem vorhergehenden Anspruch, die ferner eine Analysekomponente zum Analysieren der aufgefüllten Antwort- und Ursachencodes aufweist, um einen oder mehrere ungültige verschachtelte Aufrufe an den gemeinsam genutzten Speicherbereich des Programms zu identifizieren.
Vorrichtung nach Anspruch 10, die ferner eine darstellende Komponente zum Erzeugen einer Nachricht aufweist, die den einen oder mehrere ermittelte Konflikte zum Senden einer integrierten Entwicklungsumgebung eines Diagnosetools an einen Compiler aufweist.
Computerprogramm, aufweisend Computerprogrammcode, um, wenn er in ein Computersystem geladen und ausgeführt wird, sämtliche Schritte des Verfahrens nach irgendeinem der Ansprüche 1 bis 9 auszuführen.