DE69801332T2 - Speicherzuordnung - Google Patents
SpeicherzuordnungInfo
- Publication number
- DE69801332T2 DE69801332T2 DE69801332T DE69801332T DE69801332T2 DE 69801332 T2 DE69801332 T2 DE 69801332T2 DE 69801332 T DE69801332 T DE 69801332T DE 69801332 T DE69801332 T DE 69801332T DE 69801332 T2 DE69801332 T2 DE 69801332T2
- Authority
- DE
- Germany
- Prior art keywords
- memory
- program
- allocation
- requests
- monitoring
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
- 230000015654 memory Effects 0.000 title claims description 255
- 238000000034 method Methods 0.000 claims description 77
- 230000008569 process Effects 0.000 claims description 68
- 238000012544 monitoring process Methods 0.000 claims description 21
- 238000012806 monitoring device Methods 0.000 claims description 13
- 238000001514 detection method Methods 0.000 claims description 4
- 230000004044 response Effects 0.000 claims description 4
- 230000003936 working memory Effects 0.000 claims 2
- 230000006870 function Effects 0.000 description 11
- 230000006399 behavior Effects 0.000 description 9
- 229940004975 interceptor Drugs 0.000 description 6
- 230000000694 effects Effects 0.000 description 5
- 230000001360 synchronised effect Effects 0.000 description 5
- 238000011065 in-situ storage Methods 0.000 description 4
- 230000003993 interaction Effects 0.000 description 2
- 230000009471 action Effects 0.000 description 1
- 230000004888 barrier function Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000010586 diagram Methods 0.000 description 1
- 238000010304 firing Methods 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 239000000203 mixture Substances 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 238000003860 storage Methods 0.000 description 1
- 208000024891 symptom Diseases 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
- 230000007704 transition Effects 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/362—Software debugging
- G06F11/366—Software debugging using diagnostics
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/02—Addressing or allocation; Relocation
- G06F12/0223—User address space allocation, e.g. contiguous or non contiguous base addressing
- G06F12/023—Free address space management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/14—Protection against unauthorised use of memory or access to memory
- G06F12/1416—Protection against unauthorised use of memory or access to memory by checking the object accessibility, e.g. type of access defined by the memory independently of subject rights
- G06F12/1425—Protection against unauthorised use of memory or access to memory by checking the object accessibility, e.g. type of access defined by the memory independently of subject rights the protection being physical, e.g. cell, word, block
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
- G06F2212/10—Providing a specific technical effect
- G06F2212/1052—Security improvement
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Computer Security & Cryptography (AREA)
- Debugging And Monitoring (AREA)
Description
- Die Erfindung bezieht sich auf die Überwachung und/ oder die Ausführung der Speicherzuordnung für eine Anwendung, insbesondere in C.
- Die Computer-Programmiersprache C ist eine problemorientierte Programmiersprache, die strukturiert, modular und kompiliert ist. Die weit bekannte Sprache ist in den frühen 70er Jahren entwickelt worden. Sie kann in verschiedenen Umgebungen arbeiten, einschließlich der MS-DOS Umgebung und der UNIX-Umgebung. Ein Aspekt der C-Programme ist die Manipulation des Speichers unter Verwendung der malloc- Funktionsfamilie (malloc, realloc, free usw.), die z. B. das Standard-C-Paket für die dynamische Speicherzuordnung bilden. Die malloc-Funkfion reserviert einen Bereich des Speichers für eine gegebene Variable. In derartigen bekannten Systemen tritt jedoch insofern ein Problem auf, als diese Routinen für die dynamische Speicherzuordnung Speicher verwenden, der mit dem für den Anwender zugeordneten Speicher verschachtelt sein kann. Wenn der Anwender den Speicher überschreibt, kann der Prozeß der Speicherzuordnung verfälscht werden. Das Problem kann z. B. aus dem Freigeben nicht zugeordneten Speichers, aus dem Neuzuordnen nicht zugeordneten Speichers oder dem Schreiben außerhalb der Grenzen des zugeordneten Speichers entstehen. Alle diese Operationstypen können die Speicherzuordnungseinrichtung verfälschen. Das Freigeben nicht zugeordneten Speichers und das Neuzuordnen nicht zugeordneten Speichers verursacht oft einen unmittelbaren Absturz. Das Schreiben in einen nicht zugeordneten Speicher wird manchmal nur die Anwendungsdaten verfälschen, es kann aber außerdem einen Absturz zu irgendeinem späteren Zeitpunkt verursachen. Die Versuche, die Probleme zu verfolgen, die unter einem Diagnoseprogramm ablaufen, oder das Einfügen von Diagnosecode können beide bei der Lösung des Problems fehlschlagen, da sie die Ausführungsumgebung ausreichend modifizieren können, um das ursprüngliche Problem zu maskieren. EP-A-729097 beschreibt z. B. ein Diagnosesystem, das die Speicherzugriffsfehler eines Anwendungsprogramms überwacht; während die Überwachung während der Laufzeit stattfindet, läuft das Anwendungsprogramm innerhalb der Diagnose-Systemumgebung.
- Als ein Beispiel des Einfügens von Diagnosecode beschreibt Proceedings of the Winter USENIX Conference, 20. O1. 92, Seiten 125-136, Reed Hastings u. a.: "Purify: Fast Detection of Memory Leaks and Access Errors" ein Werkzeug, das durch das direkte Einfügen zusätzlicher Prüfbefehle in den Maschinencode der Anwendung Speicherlöcher und Zugriffsfehler erfaßt.
- Das Dokument "Static Detection of Dynamic Memory Errors", Evans, D., ACM SIGPLAN NOTICES, 1. Mai 1996, Seiten 44-53 beschreibt die Verwendung von Kommentaren zur Erfassung von Kompilierungsgzeit-Fehlern, wie z. B. toten Speicher, Speicherlöcher und gefährliche Verbindung. Dies fügt zusätzliche Komplikationen ein.
- Um diese Probleme zu vermeiden oder wenigstens zu verringern, schafft die Erfindung in einem ersten Aspekt eine Vorrichtung zur Überwachung der Zuordnung von Speicherplatz während der Laufzeit eines Programmes, das Anforderungen für Speicherzuordnungen macht, gekennzeichnet durch eine Überwachungsvorrichtung, die bei ihrer Verwendung dazu ausgelegt ist, als ein von den Programmen getrennter Prozeß ausgeführt zu werden, und die eine Zuordnungsvorrichtung aufweist, die auf Speicheranforderungen des Programms anspricht und dazu ausgelegt ist, als Antwort darauf Speichersegmente zuzuordnen.
- In einem zweiten Aspekt schafft die Erfindung ein Verfahren zur Überwachung der Zuordnung von Speicherplatz während der Laufzeit eines Programms, das umfaßt:
- (1) Ausführen des Programms, wobei das Programm Anforderungen für Speicherzuordnungen macht,
- (2) Betreiben einer Überwachungsvorrichtung als einen vom Programm getrennten Prozeß, die auf Anforderungen für Speicherzuordnungen anspricht, und
- (3) Zuordnen von Speichersegmenten an das Programm durch die Überwachungsvorrichtung als Antwort auf die Anforderungen für Speicherzuordnungen.
- In einer bevorzugten Ausführungsform werden ungültige Anforderungen für Speicherzuordnungen durch einen Überwachungs-Unterprozeß erfaßt, wobei der Überwachungs-Unterprozeß nach der Erfassung einer ungültigen Anforderung für Speicherzuordnung die Anwendung unterbricht. Im Ergebnis werden, wenn das System läuft, zuverlässigere Anwendungen erreicht, wobei ein Speicherloch identifiziert und zugestopft werden kann, was die Wahrscheinlichkeit verringert, daß Programme aus dem Speicherplatz laufen, wobei eine verbesserte Geschwindigkeit erreicht wird, da die Speicher-Seiteneinteilung verringert werden kann.
- Die Erfindung ist insofern flexibel, als ihre Verwendung nicht von einem Diagnoseprogramm abhängig ist, wobei sie ohne ein Diagnoseprogramm verwendet werden kann, wobei in diesem Fall, falls die Anwendung unterbrochen hat, der Anwender die Wahl hat, fortzusetzen oder abzubrechen. Alternativ kann anschließend ein Diagnoseprogramm verwendet werden, um die ungültige Anforderung zu untersuchen. Alternativ kann der Unterprozeß mit einem Diagnoseprogramm verwendet werden, wobei in diesem Fall das Diagnoseprogramm nach einer Unterbrechung in die Anwendung übergehen wird.
- Eine Liste des zugeordneten Speichers kann von dem Überwachungs-Unterprozeß verwaltet werden, was eine noch weiter verbesserte Speicherüberwachung ermöglicht. Die ungültigen Anforderungen für Speicherzuordnungen können eine oder mehrere Anforderungen aus folgender Gruppe aufweisen:
- gibt nicht zugeordneten Speicher frei,
- gibt bereits freigegebenen Speicher frei,
- ordne nicht zugeordneten Speicher neu zu,
- ordne bereits freigegebenen Speicher neu zu,
- ordne oder ordne neu eine negative Menge von Speicher,
- eine Menge von Speicher mit Größe Null oder eine übermäßige Menge von Speicher zu,
- die Speicherzuordnungseinrichtung ist verfälscht.
- Die Anforderungen für Speicherzuordnungen können durch einen Zuordnungs-Unterprozeß außerhalb der Anwendung ausgeführt werden. Die Speicherverwendung des Zuordnungs- Unterprozesses und der Anwendung kann beim Start der Anwendung synchronisiert werden. Im Ergebnis kann der Anwendungsprozeß und/oder die Speicherüberwachungseinrichtung in einer Umgebung ablaufen, die garantiert sicher ist. Infolge der Speichersynchronisation schickt die Speicherzuordnungseinrichtung eine gültige Adresse zurück.
- Beim Start der Anwendung kann der Überwachungs-Unterprozeß gestartet werden, wobei eine oder mehrere Anwenderoptionen aus der folgenden Gruppe dargestellt werden können:
- aktiviere den Überwachungs-Unterprozeß;
- aktiviere den Zuordnungs-Unterprozeß;
- schaffe eine größere Zuordnung als die angeforderte Speicherzuordnung;
- setzte einen Unterbrechungspunkt;
- stelle einen Lochbericht dar.
- Die Anwendung kann unter der Computer-Sprache C laufen,
- wobei die Anforderungen für Speicherzuordnungen unter der malloc-Funktionsfamilie ausgeführt werden. Alternativ kann die Erfindung unter Verwendung der malloc-Familie und außerdem der "new"- und "delete"-Operatoren auf C++ ausgedehnt werden. Da "new" und "delete" auf einer niedrigeren Ebene in Form von "malloc" und "free" implementiert werden können, wird die Anwendbarkeit der Erfindung unvermindert sein. Alle "realloc"-Aufrufe können durch die "malloc + copy"- Operation ersetzt werden.
- Gemäß der Erfindung wird ein System geschaffen, das die Zuordnung von Speicherplatz ausführt, der von einer Anwendung angefordert wird, wobei die Anforderungen für Speicherzuordnungen zu einem Zuordnungs-Unterprozeß außerhalb der Anwendung geleitet und von ihm ausgeführt werden, wobei die Speicherverwendung des Zuordnungs-Unterprozesses nach dem Start der Anwendung mit der Speicherverwendung der Anwendung synchronisiert wird. Die Anforderungen für Speicherzuordnungen können während der Laufzeit ausgeführt werden. Im Ergebnis kann der Betrieb der Anwendung noch sicherer geleistet werden.
- Gemäß einem weiteren Aspekt der Erfindung wird eine Computer-Vorrichtung, die eine auszuführende Anwendung umfaßt, die Zuordnung von Speicherplatz erfordert, und einen Zuordnungsprozeß außerhalb der Anwendung, der während der Laufzeit funktionsfähig ist, um die Anforderungen für Speicherzuordnungen der Anwendung auszuführen, geschaffen.
- Nun werden die Ausführungsformen der Erfindung beispielhaft unter Bezugnahme auf die Figuren beschrieben, worin:
- Fig. 1 ein Computer-System zeigt, das eine Anwendung enthält, die eine Speicherzuordnungseinrichtung der Sprache C verwendet, um auf den Speicher zuzugreifen;
- Fig. 2 ein Ablaufplan ist, der den Betrieb einer "clean"-Anwendung veranschaulicht;
- Fig. 3a eine unter der vorliegenden Erfindung gebundene Anwendung veranschaulicht;
- Fig. 3b die Listen der zugewiesenen und freien Speichersegmente veranschaulicht, die unter der vorliegenden Erfindung verwaltet werden;
- Fig. 4 die Anwendung nach Fig. 3 zeigt, die unter einem Überwachungs-Unterprozeß läuft;
- Fig. 5 die Anwendung nach Fig. 4 zeigt, die außerdem unter einem Schatten-Unterprozeß läuft;
- Fig. 6 ein Blockschaltplan ist, der die Wechselwirkung der verschiedenen Unterprozesse veranschaulicht;
- Fig. 7 ein Ablaufplan ist, der den Startdialog veranschaulicht;
- Fig. 8 die Verfälschung des Speichers in einer Form veranschaulicht;
- Fig. 9 die Verfälschung des Speichers in einer anderen Form veranschaulicht;
- Fig. 10 die Verfälschung des Speichers in einer anderen Form veranschaulicht;
- Fig. 11 die Verfälschung des Speichers in einer weiteren Form veranschaulicht;
- Fig. 12a einen Aufruf für malloc unter einem herkömmlichen System zeigt;
- Fig. 12b einen Aufruf für malloc unter der Erfindung zeigt; und
- Fig. 13 einen Aufruf für malloc unter der Erfindung zeigt, der einen Namenskonflikt vermeidet.
- Die Einzelheiten der Programmiersprache C sind dem Fachmann bekannt und werden hier nicht wiedergegeben. C-Programme können in einem weiten Bereich üblicherweise verfügbarer Computer-Systeme unter verschiedenen Umgebungen laufen, wie z. B. DOS und UNIX. Ein in C geschriebenes Programm wird von einem getrennten Kompiliererprogramm kompiliert, das den Maschinencode erzeugt, der von dem Computer ausgeführt wird, auf dem das Programm abläuft. Im Ergebnis ist C über verschiedene Computer-Systeme austauschbar. Die Sprache ist besonders nützlich für kompakte, schnell ausgeführte Programme, die zwischen Computern transportierbar sein müssen. Ein Aspekt der Sprache C ist die Aufnahme der malloc-Funktionsfamilie, die eingefügt wurde, um Schwierigkeiten zu vermeiden, wenn eine Variable oder eine Zeichenkette als ein Zeiger auf eine Speicherstelle einer Adresse vereinbart ist. In diesen Fällen wird die automatische Zuordnung von Speicherplatz nicht ausgeführt; statt dessen wird auf eine zufällige Stelle im Speicher gezeigt.
- In Fig. 1 ist ein herkömmliches Computer-System gezeigt, das mit der Umgebung der Sprache C arbeitet, wobei es eine Anwendung 10, eine Speicherzuordnungseinheit 12 und einen Speicher 14 umfaßt. Wie im folgenden ausführlicher beschrieben ist, gibt die Anwendung 10, wenn sie Speicher erfordert, einen Befehl aus der malloc-Funktionsfamilie aus, wobei die Einheit 12 die Speicherzuordnung des Speichers 14 bearbeitet. Die Speicherzuordnung ist schematisch als eine Zeichenkette der Adressen UUUAAUUUAA... gezeigt, wobei U der Anwendung 10 zugeordneter Speicher ist, während A ein reservierter Speicherplatz für die Zuordnungseinheit 12 ist, der für den Zweck der Verwaltung und Überwachung erforderlich ist. Wie im folgenden ausführlicher beschrieben ist, ergeben sich z. B. Probleme, wenn ein Anwender versucht, zugeordneten Speicher zu überschreiben, und insbesondere versucht, für die Zuordnungseinheit 12 reservierte Speicherplätze zu überschreiben.
- Ungeachtet der Einführung der malloc-Funktionsfamilie können jedoch die oben ausführlicher erörterten Probleme immer noch auftreten. In den Fig. 2 bis 6 schafft die Erfindung einen Prozeß, der derartige Probleme sowohl mit den Funktionen der malloc-Typs als auch mit den vorausgehenden Vorschlägen zur Verfolgung dieser Probleme durch das Ausführen unter einem Diagnoseprogramm oder das Einfügen von Diagnosecode löst.
- Durch das in dem Ablaufplan nach Fig. 2 veranschaulichte C- Programm wird eine "clean"-Anwendung demonstriert. Im Schritt 16 wird für drei Variable eine Zeichenkette definiert. Im Schritt 18 wird unter Verwendung der malloc-Funktion jeder Variable Speicher zugeordnet. Der nächste Befehl ist, im Schritt 20 den einer dieser Variable zugeordneten Speicherplatz freizugeben. Da es keine Inkonsistenzen gibt, die zu einer Verfälschung der Speicherzuordnungseinrichtung führen, treten beim Ausführen des Programms keine Probleme auf. Die entsprechende Programmliste und die entsprechende Programmausgabe, die im Anhang A1 gezeigt sind, veranschaulichen das, was unter der vorliegenden Erfindung erzeugt wird, wobei sie im folgenden ausführlicher erörtert sind.
- Als eine Veranschaulichung der Probleme, die sich ergeben können, wird, falls andererseits der anfängliche Befehl darin besteht, Speicher freizugeben, der nicht zugeordnet worden ist, dies offensichtlich zu einer Verfälschung führen. Die entsprechende Programmliste und die nachfolgende Ausgabe gemäß der vorliegenden Erfindung sind im Anhang A2 gezeigt, wobei sie im folgenden ausführlicher erörtert sind.
- Die Erfindung überwindet diese Probleme durch das Ausführen von Unterprozessen, die dynamische Speicherzuordnungen in einer C-Anwendung verfolgen oder optional ausführen, wie in den Fig. 3a, 3b, 4 und 5 gezeigt ist. Eine Maschinensprachedatei mit einem geeigneten Dateinamen, wie z. B. "dmat.o" (dmat steht für Störungssucheinrichtung für die dynamische Speicherzuordnung - dynamic memory allocation troubleshooter) 30 wird verwaltet, wobei die Anwendung 32 mit der Maschinensprachedatei 30 verbunden ist. Die Anwendung 32 wird dann in der normalen Weise aufgerufen, die für den Fachmann offensichtlich sein wird. Sobald die Anwendung eine erste dynamische Speicherzuordnung versucht, wird ein Überwachungs- Unterprozeß "dmat" 34 gebildet. Dieser Unterprozeß 34 überwacht die Korrektheit der Anforderungen für Speicherzuordnungen und veranlaßt, daß die Anwendung unterbrochen wird, wenn Probleme erfaßt werden. Der Unterprozeß 34 verwaltet die Listen 36, 38 der zugeordneten und freigegebenen Speichersegmente 40 zusammen mit ihren Größen. Diese Listen werden konsultiert, wenn die Anwendung Speicherzuordnungsoperationen ausführen muß. Weil die Speicherzuordnung in einem unabhängigen Prozeß verfolgt wird, wirken sich die Verfolgungsoperationen nicht auf das Verhalten der Anwendung aus. Demzufolge wird der Quellcode nicht modifiziert, wobei er seine Verarbeitung in getrennten Prozessoren ausführt, so daß das Verhalten der Anwendung nicht modifiziert wird, wenn der Unterprozeß eingebunden wird (falls nicht eine Verfälschung des Stapelspeichers die Wurzel des Problems ist).
- Ein zweiter dmat-Unterprozeß 42 wird hervorgebracht, wie in den Fig. 5 und 6 gezeigt ist. Dieser zweite Unterprozeß 42 übernimmt die Speicherzuordnungsoperationen vom Anwendungsprozeß 32, wobei er ihm erlaubt, in einer Umgebung abzulaufen, die garantiert sicher ist, wobei er daher eine Möglichkeit schafft, ein fehlerhaftes Programm auszuführen.
- Für die meisten Diagnose- und Überprüfungszwecke wird der Zuordnungs-Unterprozeß lediglich im Zusammenhang mit dem Überwachungs-Unterprozeß verwendet, weil das Melden von Fehlern - wie es durch den Überwachungs-Unterprozeß bereitgestellt wird - immer notwendig sein wird.
- Bei der Verwendung in kritischen Anwendungen kann es jedoch wünschenswert sein, den Zuordnungs-Unterprozeß in einer endgültigen Anwendung auszuführen, anstatt gerade während der Fehlersuche, was die Chancen eines Ausfalls noch weiter verringern könnte oder wenigstens einen Programmabsturz verzögert.
- Im folgenden ist der Betrieb des Systems ausführlicher erörtert, aber im Kern verfolgt die Überwachungseinrichtung alle Speicherzuordnungsoperationen und signalisiert die Inkonsistenzen. Die Speicherzuordnungseinrichtung 42 synchronisiert sich anfangs selbst mit der Speicherverwendung durch das Programm des Anwenders. Die Anforderungen für dynamischen Speicher werden im Speicherzuordnungsprogramm und nicht im Anwenderprogramm ausgeführt. Die Speicherzuordnungseinrichtung 42 schickt eine Adresse zurück, die infolge der anfänglichen Synchronisation im Kontext des Anwenderprogramms 32 gültig ist. Falls das Anwenderprogramm 32 einen Bereich außerhalb seines zugeordneten Speichers verfälscht, beeinflußt es nur seinen lokalen Speicher und nicht den der Speicherzuordnungseinrichtung 42. Die Integrität des Speicherzuordnungsprozesses ist deshalb nicht durch Anwenderfehler störbar.
- Wie in Fig. 5 ersichtlich ist, kann der zweite Unterprozeß 42 als ein Schatten-Unterprozeß betrachtet werden. Die Anwendung 32 und der Schatten-Unterprozeß 42 kommunizieren in Form von Speicherunterbrechungen. Wie dem Fachmann wohlbekannt sein wird, umfassen diese Speicherunterbrechungen die zugrundeliegenden Mechanismen, auf denen die dynamische Speicherzuordnung basiert, auf die durch geeignete Systemaufrufe zugegriffen werden kann, z. B. die Systemaufrufe "brk()" und "sbrk( )". Unter diesem System verhandeln der Anwendungsprozeß 32 und der Schattenprozeß 42, um ihre Speicherunterbrechungen abzustimmen. Dann wird jede Anforderung für eine Zuordnungsoperation zum Schattenprozeß 42 geleitet, wo sie ausgeführt wird, wobei die neuen Unterbrechungen zur Anwendung zurückgeleitet werden.
- Der Überwachungs-Unterprozeß 34 sollte niemals ausfallen, es ist jedoch selbstverständlich möglich, den Schatten-Unterprozeß 42 zum Absturz zu bringen, indem er gezwungen wird, Operationen auszuführen, die während des Betriebs der Erfindung für gefährlich gehalten werden. Unter diesen Umständen wäre die Anwendung außerdem selbst ausgefallen.
- Der Schattenprozeß 42 wird nun unter Bezugnahme auf die Fig. 6 und 7 ausführlicher beschrieben.
- Aus Fig. 6 ist ersichtlich, daß die Speicherzuordnungseinheit 42 alle Speicherverhandlungen mit der Speicherzuordnungseinheit 12 bearbeitet, wobei sie im Gegensatz zu der in Fig. 1 gezeigten Anordnung effektiv einen Schild oder eine Barriere zwischen der Einheit 12 und dem Anwenderprogramm oder der Anwendung 32 bildet. Der Speicher 14 besitzt ein erstes Segment 44, das als eine Zeichenkette der Speicherstellen UUUXXUUUXXUUU... schematisch gezeigt ist, wobei U dem Anwendungsprogramm zugeordnete Speicherplätze sind, während X nicht zugeordnete Speicherplätze sind. Ein weiteres Speichersegment 46 ist vorgesehen, daß in jeder Hinsicht dem Speichersegment 44 entspricht, mit Ausnahme, daß die Speicherplätze als ... dargestellt sind, wobei X nicht verwendeten Speicher darstellt, während A Speicher darstellt, der durch die Zuordnungseinheit für die Zwecke der Verwaltung und Überwachung reserviert ist.
- Folglich verfolgt die Zuordnungseinheit 42 die Zuordnung des Speichers zur Anwendung 32, wobei sie ein Segment des Speichers behält, das dem Anwendungsprogramm 32 dieser Zuordnungseinrichtung 2 entspricht. Sie führt dies aus, indem sie sichert, daß nach dem Start der Anwendung die Zuordnungseinrichtung 42 und die Anwendung 32 hinsichtlich ihres "Unterbrechungs"-Wertes durch eine Startdialogeinheit 48 synchronisiert werden. Dieses ist ein Standard-Unix-Prozeß, wobei ein Unterbrechungswert die erste freie Adresse darstellt, die dynamisch zugeordnet werden kann. Obwohl die Speichersegmente 44 und 46 verschiedene physikalische Speicherstellen besitzen, besitzen sie folglich für den Zweck der Anwendung die gleiche virtuelle Adresse. Das Sichern, daß die Zuordnungseinrichtung 42 und die Anwendung 32 mit dem gleichen Unterbrechungswert synchronisiert oder initialisiert werden, sichert automatisch, daß die Programmsegmente 44 und 46 mit genau der gleichen Struktur entwickelt werden.
- Um die zwei Unterbrechungen einander anzugleichen, besitzt ein Startdialog die Form:
- Hauptprozeß an Schattenprozeß: "Meine Unterbrechung befindet sich bei der Adresse xxx, setze deine auf diesen Wert",
- Schattenprozeß an Hauptprozeß: "Ok, erledigt", oder:
- Schattenprozeß an Hauptprozeß: "Das kann ich nicht! Sie ist bereits höher als diese, bei yyy",
- Hauptprozeß (an sich selbst): "Ok, dann setze ich meine eben auch auf yyy".
- In der Praxis ist das letztere unwahrscheinlich (aber leicht abzuwickeln), weil das Hauptprogramm wahrscheinlich größer als der Schattenprozeß ist, wobei deshalb seine Unterbrechung wahrscheinlich die größere der zwei ist.
- Mit den synchronisierten Unterbrechungen ist nun garantiert, daß eine Anforderung für Speicherzuordnung im Hauptprogramm das gleiche Ergebnis wie im Schattenprozeß ergibt. Anstatt der folgenden Wechselwirkung mit der Speicherzuordnungseinrichtung 12 aus dem echten Leben:
- Hauptprozeß an eingebaute Zuordnungseinrichtung:
- "Gib mir 100 Bytes",
- eingebaute Zuordnungseinrichtung: (bewegt die Unterbrechung möglicherweise 100 Bytes nach oben, möglicherweise mehr, und möglicherweise überhaupt nicht, falls sie freigegebenen Platz neu verwendet) "Ok, verwende den Speicher bei der Adresse zzz",
- verwandelt sich dieses mit der Unterstützung eines Schattenprozesses deshalb in:
- Hauptprozeß an (abgefangene) Zuordnungseinrichtung:
- "Gib mir 100 Bytes",
- (abgefangene) Zuordnungseinrichtung an Schattenprozeß: "Gib mir 100 Bytes",
- eingebaute Zuordnungseinrichtung des Schattenprozesses: (bewegt die Unterbrechung möglicherweise 100 Bytes nach oben, möglicherweise mehr, und möglicherweise überhaupt nicht, falls sie freigegebenen Platz neu verwendet) "Ok, verwende den Speicher bei der Adresse zzz und bewege die Unterbrechung zu bbb",
- (abgefangene) Zuordnungseinrichtung an Hauptprozeß (bewegt die Unterbrechung, falls/wie sie gerichtet ist): "Ok, verwende den Speicher bei der Adresse zzz".
- Auf diese Weise wird die 'Unterbrechung' des Hauptprozesses genauso manipuliert, als ob die Speicherzuordnungseinrichtung es ausführen würde, falls aber das Anwenderprogramm den Speicher verfälscht, den die Zuordnungseinrichtung normalerweise für ihre eigenen Vorrichtungen verwenden würde, eignen sich keine schlimmen Sachen, weil sich der tatsächliche Arbeitsspeicher für die Zuordnungseinrichtung in einem getrennten Prozeß befindet.
- Die Verfälschung des Speichers kann bedeuten:
- - das Überschreiben der Anwenderdaten,
- - das Überschreiben des Bereichs, der von der Speicherzuordnungseinrichtung selbst verwendet wird.
- Der Schattenprozeß verhindert die zweite dieser Wirkungen, nämlich die Verfälschung der Speicherzuordnungseinrichtung. In einem Programm könnte es in der Tat den folgenden Dialog geben, nämlich:
- Anwenderprogramm: Gib mir 100 Bytes des Speichers (Bereich A),
- Zuordnungseinrichtung: Ok, die Adressen 2000 bis 2099 sind deine,
- Anwenderprogramm: Gib mir andere 100 Bytes des Speichers (Bereich B),
- Zuordnungseinrichtung: Ok, 2120 bis 2219 sind deine.
- (Es wird angemerkt, daß die Zuordnungseinrichtung ganz realistisch keinen zusammenhängenden Bereich bereitstellt. Hier läßt sie die 20 Bytes bei den Adressen 2100 bis 2119 aus.)
- Es folgen nun einige typische Programmierfehler:
- 1) das Anwenderprogramm schreibt fälschlicherweise das 200. Byte des Bereichs A, der tatsächlich lediglich 100 Bytes lang ist. Die Wirkung ist, daß ein Teil des Bereichs B modifiziert wird, so daß, wenn der Anwender auf ihn zugreift, er einen unerwarteten Wert enthalten kann;
- 2) das Anwenderprogramm schreibt fälschlicherweise das 110. Byte des Bereichs A. Dies befindet sich in dem Bereich, der von der Speicherzuordnungseinrichtung selbst verwendet wird, und wenn die Speicherzuordnungseinrichtung abermals aufgerufen wird, ist es wahrscheinlich, daß irgend etwas ausfällt, die Symptome sind aber schwierig vorherzusagen;
- dmat überwindet diesen zweiten Fehlertyp. Sie führt dies durch das Abfeuern eines vollständig getrennten Unix-Prozesses, des Schattenprozesses 42, aus, speziell um die Speicherzuordnung zu unterstützen. dmat fängt außerdem die ursprünglichen Aufrufe für die Speicherzuordnungseinrichtung ab, deshalb kann sie ihre eigenen Handlungen und Rückkehrwerte einfügen, als ob sie von der ursprünglichen Zuordnungseinrichtung gekommen waren. Nun lautet der Dialog:
- Anwenderprogramm: Gib mir 100 Bytes des Speichers (Bereich A),
- Abfangeinrichtung: Befehl an den Schattenprozeß: Gib mir 100 Bytes des Speichers,
- Schattenprozeß: Ok Abfangeinrichtung: die Adressen 2000 bis 2099 sind deine,
- Abfangeinrichtung: Ok Anwender, die Adressen 2000 bis 2099 sind deine,
- Anwenderprogramm: Gib mir 100 Bytes des Speichers (Bereich B),
- Abfangeinrichtung: Befehl an den Schattenprozeß: Gib mir 100 Bytes des Speichers,
- Schattenprozeß: Ok Abfangeinrichtung: die Adressen 2120 bis 2219 sind deine,
- Abfangeinrichtung: Ok Anwender, die Adressen 2120 bis 2219 sind deine.
- Folglich findet die tatsächliche Speicherzuordnung lediglich im Schattenprozeß statt. Der Schattenprozeß macht seinen Speicher dem ursprünglichen Prozeß nicht zugänglich - er kann es nicht, er ist vollständig getrennt. Statt dessen meldet er einfach den Adressenbereich zurück, in dem der neue Speicher verfügbar ist. Das ursprüngliche Programm kann dann diesen Adressenbereich in der normalen Weise verwenden.
- Es folgen nun abermals dieselben typische Programmierfehler:
- 1) das Anwenderprogramm schreibt fälschlicherweise das 200. Byte des Bereichs A, der tatsächlich lediglich 100 Bytes lang ist. Die Wirkung ist, daß ein Teil des Bereichs B modifiziert wird, so daß, wenn der Anwender auf ihn zugreift, er einen unerwarteten Wert enthalten kann;
- 2) das Anwenderprogramm schreibt fälschlicherweise das 110. Byte des Bereichs A. Dies befindet sich in dem Bereich, der von der Speicherzuordnungseinrichtung selbst verwendet wird, die Speicherzuordnungseinrichtung wird aber in diesem Prozeß nicht ausgeführt, deshalb kann sie nicht verfälscht werden.
- Der Schattenprozeß besitzt zwei Anwendungen:
- Zuerst kann er innerhalb eines Werkzeugs wie dmat verwendet werden, wo er eine andere Einrichtung ist, die als ein Teil des Arsenals für die Fehlersuche verwendet werden kann.
- Anstatt der Verwendung des Schattenprozesses als ein Hilfsmittel zur Fehlersuche könnte er zweitens in ein System als ein permanenter Teil aufgenommen sein, was eine robustere Speicherzuordnung von der vorhandenen Speicherzuordnungs- Software bietet.
- Eine Fernsprechvermittlungsstelle, die ein Haupthindernis sein würde, falls sie, verursacht durch ein Problem der Speicherzuordnung, ausfällt, ist ein praktisches Beispiel. Die Software ist äußerst komplex, wobei sie (angenommen) die Verwendung der dynamischen Speicherzuordnung erfordert. Vorausgesetzt, daß es Fehler geben wird, die die Speicherzuordnungseinrichtung verfälschen könnten, und wenn die Fähigkeit besteht, diese Probleme (mit dem Schattenprozeß) zu verhindern, würde es möglich sein, die Schattenprozeß-Technik außerhalb von dmat zu verwenden, wo die dynamische Speicherzuordnung zu verwenden ist und wo optimale Robustheit erwünscht ist.
- Der Betrieb der Erfindung wird nun ausführlicher erörtert. Der Prozeß läuft in zwei Phasen. Die erste Startphase umfaßt einen Dialog, die dem Anwender erlaubt, das Verhalten des Prozesses kundenspezifisch anzupassen. Die zweite Phase umfaßt den tatsächlichen Betrieb des Prozesses, während der eine Meldung ausgegeben wird, wann immer eine unsichere Operation des dynamischen Speichers erfaßt wird.
- Es wird angemerkt, daß sich viel der spezifischen Beschreibung spezifisch auf die malloc- und free-Funktionen bezieht, daß aber die Lehren genau so auf andere Operationen in der Funktion einschließlich realloc, calloc und cfree anwendbar sind, wo es geeignet ist.
- Der Startdialog ist in dem Ablaufplan nach Fig. 7 veranschaulicht. Wie ersichtlich ist, wird der Anwender, wenn der Prozeß startet, durch einen Satz von Konfigurationsfragen geführt. Jede Frage ist durch einen Kasten im Ablaufplan dargestellt, wobei bevorzugt eine vorgegebene Option gesetzt ist, die durch einen Pfeil dargestellt wird, der am Boden des Kastens beginnt und den Programmfluß zeigt, der der vorgegebenen Antwort folgt. Die nicht vorgegebene Antwort wird durch einen Pfeil dargestellt, der sich von einer Seite des Kastens im in Fig. 7 gezeigten Ablaufplan erstreckt. Die Implementierung des Dialogs kann selbstverständlich in irgendeiner geeigneten Form erfolgen, die nicht vorgegebene Antwort kann aber z. B. durch das Drücken des Buchstabens erhalten werden, der in der Dialogfrage angegeben ist, während die vorgegebene Antwort durch das Drücken des Wagenrücklaufs erhalten werden kann. Die Optionen sind vorzugsweise alle so ausgedrückt, um soweit wie möglich die gleiche vorgegebene Antwort zu erlauben (z. B. "ja"). Die vorgegebenen Optionen sind vorzugsweise so gesetzt, daß durch die Vorgabe die häufigste Betriebsart ausgewählt wird, was die Anwendereingabe dementsprechend verringert.
- Zuerst wird im Schritt 50 dem Anwender die Option gegeben, ob er den Prozeß aktiviert oder nicht. Falls die Antworten nein lautet, hält der Prozeß im Schritt 52 an. Falls die vorgegebene Antwort ja ausgewählt wird, geht der Dialog zum Schritt 54 weiter, in dem dem Anwender die vorgegebene Option gegeben wird, den Zuordnungs-Unterprozeß zu verwenden, insbesondere die Anwendungen der Routinen malloc, realloc und free, die in der vorgegebenen Option im Schritt 56 aus der C-Bibliothek eingebunden werden, um den dynamischen Speicher zu manipulieren, was eine größere Elastizität für die Verfälschung der Zuordnungseinrichtung gibt.
- Der Dialog geht dann zum Schritt 58 weiter, der dem Anwender die vorgegebene Option des Standardverhaltens in bezug auf die dynamische Speicherzuordnung erlaubt, d. h. die im folgenden erörterte Vorgabe der Schritt 60, 64 und 66, wobei erlaubt ist, diese Schritte zu überspringen und direkt zum im folgenden erörterten Schritt 70 weiterzugehen. In der Alternative kann der Prozeß die malloc-, realloc- und free-Aufrufe abfangen und verschiedene Modifikationen ihres Verhaltens anwenden.
- Im Schritt 60 kann der Anwender entweder der vorgegebenen Option, wobei in diesem Fall der Prozeß die Aufrufe für free zur C-Bibliothek leitet, oder der alternativen Option, bei der die free-Anforderungen ignoriert werden [Schritt 62], folgen. Falls das Ignorieren der Aufrufe für free das Verhalten einer Anwendung ändert, ist es gut möglich, daß sie verdächtige Aufrufe enthält.
- Mit dem Weitergehen zum Schritt 64 wird dem Anwender die vorgegebene Option angeboten, daß die Aufrufe für realloc direkt zur C-Bibliothek geleitet werden. Alternativ werden die realloc-Anforderungen, die in situ erfüllt würden (durch die Bewilligung von Speicher bei der eingespeisten Adresse anstatt bei einer neuen Adresse), durch malloc plus copy-Aufrufe simuliert [Schritt 65]. Durch das Folgen dieser Option können die Wirkungen des Leitens von realloc zu einer ungültigen Adresse vermieden werden. Falls das Sperren der in-situreallocs das Verhalten einer Anwendung ändert, ist es gut möglich, daß sie verdächtige Aufrufe enthält.
- Als ein Beispiel, wie realloc durch malloc + copy simuliert wird, werden 100 Bytes des Speichers zugeordnet durch:
- a = malloc(100);
- wobei, falls später erwünscht ist, es auf 200 Bytes auszudehnen, "realloc" verwendet wird:
- a = realloc(a, 200);
- Was realloc genau tut, hängt von der Implementierung ab, falls aber der Speicher gerade nach dem ursprünglichen Ende von "a" bereits verwendet wird, muß er "a" irgendwo anders hin kopieren und einen neuen Wert für "a" zurückschicken. Falls es jedoch einen Raum gibt, muß "realloc" nur den verfügbaren Platz für "a" ausdehnen und so die gleiche Adresse zurückschicken. Die Situation wird als ein "in situ"-realloc bezeichnet.
- Falls nun ein Programmfehler bedeutet, daß "a" nicht länger eine gültige Adresse enthält, dann ist es wahrscheinlich, daß:
- a = realloc(a, 200);
- fehlschlägt, weil "realloc" fehlerhafte Informationen weiterreicht.
- Die "malloc + copy"-Operation fängt alle "realloc"-Aufrufe ab und ersetzt sie (für das aktuelle Beispiel) mit:
- new_a = malloc(200);
- memcpy(new_a,a,200);
- Die Tatsache, daß "a" einen fehlerhaften Wert enthält, macht auf diese Weise nichts. Wie bei dmat im allgemeinen würde diese Taktik versucht werden, sehen was passiert, und einiges aus den Ergebnissen folgern.
- Der vorgegebenen Option folgend wird im Schritt 66 die Menge des in den Aufrufen für malloc und realloc angeforderten Speichers zugewiesen. In der Alternative [Schritt 68] kann der angeforderte Speicher innerhalb einer größeren Zuordnung angeordnet werden. Der Anwender ist eingeladen, die oberen und unteren Grenzen in Bytes für den Schutzbereich einzugeben. Ein vom Anwender auf Null Bytes darunter und 4 Bytes darüber gesetzter Schutzbereich würde z. B. die Wirkungen des Schreibens eines Elements über das Ende des dynamisch zugeordneten Bereichs vermindern. Die oberen und unteren Schutzbereiche werden durch eine positive Anzahl von Bytes ausgedrückt. Diese Zahlen werden auf ein Vielfaches von 4 Bytes aufgerundet, um Probleme der Ausrichtung des Speichers zu vermeiden.
- Der Prozeß geht nun zum Schritt 70 weiter, der außerdem direkt von der nicht vorgegebenen Option des Schritts 58 erreicht worden sein kann. Der Anwender hat die Gelegenheit, den Unterbrechungspunkt als eine Zahl zu setzen. In der vorgegebenen Option wird die Anwendung ausgeführt, bis sie ein Problem erfaßt. Alternativ kann der Prozeß bei einer vom Anwender gesetzten spezifischen Operation angehalten werden [Schritt 71]. Der vorgegebene Wert ist auf null gesetzt, der einfach bedeutet, nicht anzuhalten, da dmat mit der Operation 1 beginnt. Im allgemeinen wird ein Unterbrechungspunkt gesetzt, nachdem ein vorausgehender Ablauf der Anwendung eine verdächtige Operation gemeldet hat. Wenn einem Unterbrechungspunkt begegnet wird, kann der Zustand der Anwendung mit einem Diagnoseprogramm untersucht werden.
- Nun kann der Anwender durch das Weitergehen zum Schritt 72 wählen, ob eine "Lochmeldung" auszulassen ist (in der vorgegebenen Option). In der Alternative wird der ausstehende nicht freigegebene Speicher gemeldet, wenn die Anwendung abgeschlossen wird. Die vorgegebene Option ist auf "auslassen" gesetzt, weil ansonsten die sich ergebene Ausgabe sehr lang sein kann.
- In bezug auf die Lochmeldung für komplexe Situationen sollte im Gedächtnis behalten werden, daß verschiedene Funktionen der C-Bibliothek selbst die dynamische Speicherzuordnung verwenden - z. B. "fprinf". Etwas von diesen Speicher kann bis nach dem Abschluß des dmat-Überwachungsprozesses nicht freigegebene sein (was der erste unternommene Schritt ist, wenn der Prozeß verlassen wird). Nicht geschlossene Dateien können zum Speicherloch beitragen.
- Der Dialog ist dann abgeschlossen, wobei bei 74 die Anwendung in die Laufzeit-Phase eintritt.
- Der Betrieb der zweiten Laufzeit-Phase wird am besten beispielhaft erklärt. Während dieser Phase überwacht ein erster Unterprozeß die Anforderungen für Zuordnungen, während ein zweiter Unterprozeß optional alle Zuordnungen ausführt. Demzufolge werden alle Aufrufe für malloc, realloc und free überwacht, wobei Unregelmäßigkeiten gemeldet werden. Wie oben in bezug auf Fig. 2 und Anhang A1 erörtert ist, druckt der Prozeß bei einer "clean"-Anwendung einfach ein Spruchband, das anzeigt, daß er betriebsfähig ist, und eine Schlußstatistik, die z. B. die Anzahl der malloc-, realloc- und free-Aufrufe darlegt. Die realloc-Statistik kann die Anzahl der Aufrufe in situ und der Kopieraufrufe spezifizieren. Außerdem werden der maximal zugeordnete Speicher und der endgültig zugeordnete Speicher (der infolge des Freigebens einer der Variable verringert worden sein wird) angegeben.
- Wie oben in bezug auf Anhang A2 erörtert ist, wird die Anwendung angehalten, wenn einem Problem begegnet wird, wobei, abhängig von der Natur des Problems, verschiedene Optionen angeboten werden. Die Fehlermeldung gibt vorzugsweise die Operationsnummer an, wobei sie einen Erklärungstext bereitstellt, was die verfügbaren Optionen anbelangt. Ähnlich zum Betrieb des Startdialogs überträgt jede Fehlermeldung vorzugsweise eine vorgegebene Option (die z. B. mit einem Wagenrücklauf erhalten wird) unter der sich die Anwendung verhält, als ob der Überwachungsprozeß fehlen würde; d. h. die Operation wird ausgeführt, wenngleich sie verdächtig ist. Wenn z. B. eine Anwendung versucht, Speicher freizugeben, der nicht zugeordnet worden ist, dann wird eine Fehlermeldung erzeugt, die die Operationsnummer angibt, die den Fehler verursacht hat, wobei die Optionen Abbrechen, Ausführen oder Auslassen angeboten werden. Abbrechen beendet das Programm, Ausführen führt die verdächtige Operation aus, wobei die Anwendung fortgesetzt wird, während Auslassen der Anwendung erlaubt, ohne das Ausführen der verdächtigen Operation fortzufahren. Ein bevorzugtes Format, in der die Optionen dargelegt werden, ist im Anhang A2 gezeigt.
- Außer dem Freigeben von nicht zugeordneten Speicher, wie oben erörtert ist, können gemäß der Erfindung verschiedene andere Probleme behandelt werden.
- Der Prozeß erfaßt Versuche, Speicher freizugeben, der vorausgehend zugeordnet und anschließend freigegeben worden ist. In Fig. 8 wird im Schritt 80 eine Variable als eine Zeichenkette definiert, im Schritt 82 wird durch das Aufrufen von malloc der Variable ein Speicherwert zugewiesen, im Schritt 84 wird der Speicher freigegeben und im Schritt 86 wird versucht, den Speicher abermals freizugeben. In diesem Fall erzeugt der Überwachungsprozeß eine Fehlermeldung, die anzeigt, daß im Schritt 86 ein Fehler aufgetreten ist, da der Speicher bereits freigegeben worden ist, wobei sie die Wahlmöglichkeiten des Abbrechens - beende das Programm, des Ausführens - führe die verdächtige Operation aus und setzte fort, oder des Auslassens - setzte ohne das Ausführen der verdächtigen Operation fort, bietet. Die entsprechende Programmliste und die entsprechenden Ausgangsmeldungen sind im Anhang A3 gezeigt.
- Der Prozeß kann außerdem Versuche erfassen, Speicher neu zuzuordnen, der bereits vorausgehend zugeordnet und anschließend freigegeben worden ist. In diesem Fall wird eine Fehlermeldung erzeugt, die die Operationsnummer anzeigt, und die anzeigt, dat der beabsichtigte realloc-Schritt nicht möglich war, weil die alte Adresse nicht zugeordnet worden war. Die Wahlmöglichkeiten des Abbrechens - beende das Programm, des Ausführens - führe die verdächtige realloc-Operation aus und setzte fort, oder des Rettens - ersetzte die realloc durch eine malloc und eine Speicherkopie, werden angeboten. Die Programmliste und die Ausgangsmeldungen sind im Anhang A4 gezeigt.
- In Fig. 9 erfaßt der Prozeß außerdem Versuche, eine Speicheradresse neu zuzuordnen, die vorausgehend nicht zugeordnet worden ist. Im Schritt 88 wird eine Variable als eine Zeichenkette definiert, wobei im Schritt 90 durch das Aufrufen von malloc der Variable Speicher zugeordnet wird. Im Schritt 92 wird der Speicher freigegeben, wobei im Schritt 94 das Programm versucht, eine Speicheradresse der Variable neu zuzuordnen, was fehlschlägt, weil der Speicher vorausgehend freigegeben worden war. Demzufolge wird eine Fehlermeldung erzeugt, die anzeigt, daß im Schritt 94 ein Fehler aufgetreten ist, und daß die Adresse im Schritt 92 bereits freigegeben worden war, wobei dem Anwender die Optionen des Abbrechens - beende das Programm, des Ausführens - führe die verdächtige Operation aus und setzte fort, oder des Rettens - ersetzte die realloc durch eine malloc, angeboten werden. Die entsprechende Programmliste und die entsprechenden vom Prozeß ausgegebenen Meldungen sind im Anhang A5 gezeigt.
- In Fig. 10 werden Anforderungen mit verdächtiger Speichergröße erfaßt, insbesondere Versuche, eine negative Menge von Speicher, eine Menge von Speicher mit Größe Null oder eine sehr große Menge von Speicher zuzuweisen oder neu zuzuweisen. Im Schritt 96 wird eine Variable als eine Zeichenkette definiert, wobei in den Schritten 98, 100 bzw. 102 eine negative Menge von Speicher, eine Menge null von Speicher und eine sehr große Menge von Speicher zugewiesen wird. Der Prozeß erzeugt demzufolge entsprechende Fehlermeldungen, die anzeigen, daß im Schritt 98 eine verdächtige negative Menge zugeordnet wurde, daß im Schritt 100 eine verdächtige Menge null zugeordnet wurde, und daß im Schritt 102 eine verdächtige sehr große Menge zugeordnet wurde. Der Anwender kann eine der Optionen des Abbrechens - beende das Programm, oder des Ausführens - führe die verdächtige Zuordnungsoperation aus und setzte fort, wählen. Es wird angemerkt, das ähnliche Fehlermeldungen und Optionen für die entsprechenden malloc- und realloc-Fehler verwendet werden können. Obwohl malloc und realloc das Argument der Speichermenge streng als ohne Vorzeichen interpretieren, interpretiert der Überwachungsprozeß die Größenanforderungen ähnlich, er gibt aber außerdem ein Äquivalent mit Vorzeichen, wo dies geeignet erscheint. Eine entsprechende Programmliste und die entsprechenden Ausgangsmeldungen sind im Anhang A6 gezeigt.
- In Fig. 11 können verfälschte Zuordnungen, d. h. Fälle, in denen die Speicherzuordnungseinrichtung als verfälscht worden erscheint, erfaßt werden. Im Schritt 104 werden sowohl eine erste als auch eine zweite Variable als Zeichenketten definiert. Im Schritt 106 wird durch das Aufrufen von malloc der ersten Variable Speicher zugeordnet. Eine Folge von n nachfolgenden Operationen des dynamischen Speichers sind im Schritt 108 dargestellt. Es wird angenommen, daß es kein Freigeben (free) oder kein Neuzuordnen (realloc) der ersten Variable gibt. Im Schritt 110 wird durch das Aufrufen von malloc der zweiten Variable Speicher zugeordnet. Falls die gleiche Adresse sowohl der ersten als auch der zweiten Variable zugewiesen wird, muß der Code verdächtig sein, wobei eine Fehlermeldung erzeugt wird, die angibt, daß in der (n + 2)-ten Operation [Schritt 110] die Zuordnungseinrichtung verfälscht wurde, da der gleiche Rücksprung bei der Operationsnummer 1 [Schritt 106] festgestellt wurde. Die angebotenen Auswahlmöglichkeiten sind Abbrechen - beende das Programm, oder Ausführen - führe die Zuordnungsoperation aus und setzte fort. Selbstverständlich werden ähnliche Fehlermeldungen und Optionen für alle Mischungen der Verfälschungen von malloc und realloc vorkommen. Die entsprechende Programmliste und die entsprechenden Ausgangsmeldungen sind im Anhang A7 gezeigt.
- Die Weise, in der die dmat-Anwendung die Aufrufe für "malloc", "free" usw. abfängt, sind unter Bezugnahme auf die Fig. 12 und 13 erörtert.
- Wie in Fig. 12a gezeigt ist, wechselt in herkömmlichen Systemen ohne das System der vorliegenden Erfindung ein Aufruf für malloc im Anwenderprogramm 120 direkt zu malloc in der C- Bibliothek 122.
- Wird das System der vorliegenden Erfindung eingeführt, wird ein Aufruf für malloc im Anwenderprogramm zu malloc in dmat 126 weitergeleitet und folglich zu malloc* in der C-Bibliothek 128. Die tatsächliche Zuordnung wird in der C-Bibliothek ausgeführt.
- Ferner gibt es einen Namenskonflikt, wenn das Anwenderprogramm malloc in dmat aufnehmen muß. Damit kann umgegangen werden, indem die Namen in der "C"-Bibliothek 128 des Systems (oder wenigstens einer Kopie von ihr) modifiziert werden. Das malloc-Modul wird aus der C-Bibliothek 18 extrahiert, wobei der Name malloc zu MalloC korrigiert wird. Dieses Modul wird dann als ein Teil der dmat-Anwendung geliefert, wie in Fig. 13 gezeigt ist, in der der Aufruf für malloc im Anwenderprogramm 130 zu malloc in dmat 132 und folglich zu Ma110C* in dmat 134 wechselt. Die Version der "C"-Bibliothek von malloc wird nicht verwendet (ihre Kopie innerhalb von dmat ist abgesehen von ihren Namen völlig gleich, so daß das Verhalten der Zuordnung von Speicher nicht modifiziert ist).
- Demzufolge kann die Anwendung in verschiedenen Arten verwendet werden, z. B.:
- 1 Um ein erkennbar fehlerhaftes Programm auszutesten. Abhängig vom Problem können die Laufzeit-Fehlermeldungen unzureichend seien, um die Probleme mit dem Programm anzuzeigen, oder es könnte notwendig sein, das Verhalten der Speicherzuordnung zu modifizieren (durch das Auslassen der "free"-Operationen oder durch das Verwenden des Zuordnungs-Unterprozesses), um zu erreichen, daß das Programm ausreichend arbeitet. Bei der Anwesenheit eines verdeckten Fehlers werden verschiedene Optionen und Kombinationen von Optionen versucht. Aus dem Ergebnis von diesem (d. h. die Programmausgabe kann sich ändern oder nicht, sie kann richtig werden, sie kann in einer anderen Art falsch werden) kann es möglich sein, zu schließen, was mit dem Programm nicht in Ordnung ist. Obwohl das System erreichen kann, daß ein Programm arbeitet, besteht im allgemeinen die Absicht, die zugrundeliegenden Probleme zu korrigieren, so daß das Programm arbeitet, wobei an dieser Stufe das System nicht länger verwendet werden muß.
- 2 Um ein vorgeblich richtiges Programm zu überprüfen. Falls eine Anwendung zufriedenstellend läuft, ist es Wert, das System nach verborgenen Problemen zu überprüfen. Es kann sein, daß diese Probleme gutartige Probleme sind, oder sie können Schwierigkeiten verursachen, wenn das Programm mit anderen Daten läuft. In jedem Fall ist das Überprüfen eines kritischen Programms selbstverständlich im hohen Grade wünschenswert.
- 3 Um nach einem Speicherloch in einem ansonsten zufriedenstellenden Programm zu suchen. Die Lochmeldung erlaubt, daß die Quellen des Speicherlochs verfolgt und folglich korrigiert werden.
- 4 Um während der normalen Laufzeit mit allen Speicherzuordnungsprozeduren der Hauptanwendung umzugehen.
- Es wird klar sein, daß der Speicherüberwachungsprozeß, wie er oben erörtert ist, in bezug auf irgendeine Computer-Sprache verwendet werden kann, in der die relevanten Speicherzuordnungsprobleme auftreten. Es sind z. B. andere Sprachen in der gleichen Familie wie C, z. B. C++, geeignet. Die Erfindung kann selbstverständlich auf irgendeinen geeigneten Computer-System ausgeführt werden, wenn das gewünscht ist. ANHANG A1
- Falls dmat aufgefordert wird, eine Speicherloch-Meldung zu geben, wird sie außerdem die folgende Ausgabe erzeugen: ANHANG A2 ANHANG A3 ANHANG A4 ANHANG A5 ANHANG A6 ANHANG A7
- Wenn dies a2 den gleichen Wert zuweist wie es a zuweist, dann muß der Code verdächtig sein, wobei dmat die Fehlermeldung erzeugen wird:
Claims (16)
1. Vorrichtung zur Überwachung der Zuordnung von Speicherplatz
während der Laufzeit eines Programmes (32), das
Anforderungen für Speicherzuordnungen macht,
gekennzeichnet durch
eine Überwachungsvorrichtung (30), die bei ihrer Verwendung
dazu ausgelegt ist, als ein von dem Programm getrennter Prozeß
ausgeführt zu werden, und die eine Zuordnungsvorrichtung (42)
aufweist, die auf Speicheranforderungen des Programms
anspricht und dazu ausgelegt ist, als Antwort darauf
Speichersegmente zuzuordnen.
2. Vorrichtung nach Anspruch 1, bei der die
Zuordnungsvorrichtung (42) dazu ausgelegt ist, einen
Zuordnungs-Speicherabschnitt (46) vorzuhalten, der einem von dem Programm
verwendeten Arbeits-Speicherabschnitt (44) entspricht, wobei die
Abschnitte entsprechende Strukturen aufweisen, jeder Abschnitt
erste Speicherzellen (U), die zur Verwendung durch das
Programm verfügbar sind, und zweite Speicherzellen (A) aufweist,
die zum Zweck der Verwaltung und Überwachung reserviert
sind, und wobei die Auslegung so ist, daß die ersten
Speicherzellen des Arbeits-Abschnitts verwendet werden, während die
zweiten Speicherzellen nicht zugeordnet sind, und die ersten
Speicherzellen des Zuordnungs-Abschnitts nicht zugeordnet
sind, während die zweiten Speicherzellen für Verwaltungs- und
Überwachungszwecke reserviert sind.
3. Vorrichtung nach Anspruch 2, bei der die Strukturen
Sequenzen von Gruppen von ersten Speicherzellen aufweisen, die von
Gruppen von zweiten Speicherzellen separiert werden.
4. Vorrichtung nach Anspruch 2 oder 3, bei der die
Zuordnungsvorrichtung eine Vorrichtung aufweist, die die
Unterbrechungswerte der Zuordnungs- und Arbeits-Abschnitte initialisiert, um
sicherzustellen, daß beim Start des Programms die Abschnitte
die gleiche virtuelle Adresse haben.
5. Vorrichtung nach Anspruch 1, bei der die
Überwachungsvorrichtung eine Vorrichtung (34) aufweist, die
Speicheranforderungen des Programms beurteilt und beim Feststellen einer
ungültigen Speicheranforderung die Anwendung unterbricht.
6. Vorrichtung nach Anspruch 5, bei der die
Beurteilungsvorrichtung dazu ausgelegt ist, im Speicher jeweils Listen für
zugeordnete Speichersegmente und freigegebene Speichersegmente (36,
38) zu verwalten.
7. Vorrichtung nach Anspruch 6, bei der die
Überwachungsvorrichtung dazu ausgelegt ist, ungültige Anforderungen für
Speicherzuordnungen zu ermitteln, die eine oder mehrere
Anforderungen aus folgender Gruppe aufweisen:
gib nicht zugeordneten Speicher frei,
gib bereits freigegebenen Speicher frei,
ordne nicht zugeordneten Speicher neu zu,
ordne bereits freigegebenen Speicher neu zu,
ordne oder ordne neu eine negative Menge von Speicher, eine
Menge von Speicher mit Größe Null oder eine übermäßige
Menge von Speicher zu.
8. Vorrichtung nach einem der vorhergehenden Ansprüche, bei der
die Überwachungsvorrichtung dazu ausgelegt ist, als
Maschinensprachedatei ausgebildet zu sein, die vor der Laufzeit mit
dem Programm verbunden wird.
9. Datenträger mit aufgezeichneter Überwachungsvorrichtung,
wobei die Überwachungsvorrichtung nach einem der Ansprüche
1 bis 7 ausgebildet ist.
10. Datenträger mit aufgezeichneter Überwachungsvorrichtung,
wobei die Überwachungsvorrichtung als Maschinensprachedatei
nach Anspruch 8 ausgebildet ist.
11. Verfahren zur Überwachung der Zuordnung von Speicherplatz
während der Laufzeit eines Programmes (32), das umfaßt:
(1) Ausführen des Programms, wobei das Programm
Anforderungen für Speicherzuordnungen macht,
(2) Betreiben einer Überwachungsvorrichtung (30, 42) als einen
vom Programm getrennten Prozeß, die auf Anforderungen
für Speicherzuordnungen anspricht, und
(3) Zuordnen von Speichersegmenten an das Programm durch
die Überwachungsvorrichtung als Antwort auf die
Anforderungen für Speicherzuordnungen.
12. Verfahren nach Anspruch 11, das das Vorhalten eines
Zuordnungs-Speicherabschnitts (46) umfaßt, der einem von dem
Programm verwendeten Arbeits-Speicherabschnitt (44) entspricht,
wobei die Abschnitte entsprechende Strukturen aufweisen, jede
Struktur erste Speicherzellen (U), die für die Verwendung durch
das Programm verfügbar sind, und zweite Speicherzellen (A)
aufweist, die für Zwecke der Verwaltung und Überwachung
reserviert sind, die ersten Speicherzellen des Arbeits-Abschnitts
verwendet werden, während die zweiten Speicherzellen nicht
zugeordnet sind, und die ersten Speicherzellen des Zuordnungs-
Abschnitts nicht zugeordnet sind, während die zweiten
Speicherzellen für Verwaltungs- und Überwachungszwecke
reserviert sind.
13. Verfahren nach Anspruch 12, das das Initialisieren der
Unterbrechungswerte der Arbeits- und Zuordnungs-Abschnitte
umfaßt, um sicherzustellen, daß beim Start des Programms die
Abschnitte die gleiche virtuelle Adresse haben.
14. Verfahren nach einem der Ansprüche 11 bis 13, bei dem die
Überwachungsvorrichtung (30) die Speicheranforderungen (34)
beurteilt und bei Feststellung einer ungültigen
Speicheranforderung das Programm zu einer Unterbrechung veranlaßt.
15. Verfahren nach Anspruch 14, bei dem die
Überwachungsvorrichtung zur Beurteilung von Speicheranforderungen im
Speicher jeweilige Listen für zugeordnete Speichersegmente und
freigegebene Speichersegmente (36, 38) verwaltet.
16. Verfahren nach Anspruch 14, das ungültige Anforderungen für
Speicherzuordnungen ermittelt, die eine oder mehrere
Anforderungen aus folgender Gruppe aufweisen:
gib nicht zugeordneten Speicher frei,
gib bereits freigegebenen Speicher frei,
ordne nicht zugeordneten Speicher neu zu,
ordne bereits freigegebenen Speicher neu zu,
ordne oder ordne neu eine negative Menge von Speicher, eine
Menge von Speicher mit Größe Null von Speicher oder eine
übermäßige Menge von Speicher zu.
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP97307664 | 1997-09-25 | ||
GBGB9720460.6A GB9720460D0 (en) | 1997-09-25 | 1997-09-25 | Memory allocation |
PCT/GB1998/002883 WO1999015965A1 (en) | 1997-09-25 | 1998-09-24 | Memory allocation |
Publications (2)
Publication Number | Publication Date |
---|---|
DE69801332D1 DE69801332D1 (de) | 2001-09-13 |
DE69801332T2 true DE69801332T2 (de) | 2002-05-23 |
Family
ID=26147628
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
DE69801332T Expired - Fee Related DE69801332T2 (de) | 1997-09-25 | 1998-09-24 | Speicherzuordnung |
Country Status (5)
Country | Link |
---|---|
US (1) | US6363467B1 (de) |
EP (1) | EP1015974B1 (de) |
AU (1) | AU9176698A (de) |
DE (1) | DE69801332T2 (de) |
WO (1) | WO1999015965A1 (de) |
Families Citing this family (29)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7424712B1 (en) * | 1999-04-30 | 2008-09-09 | Sun Microsystems Inc | System and method for controlling co-scheduling of processes of parallel program |
US7111307B1 (en) | 1999-11-23 | 2006-09-19 | Microsoft Corporation | Method and system for monitoring and verifying software drivers using system resources including memory allocation and access |
US6523141B1 (en) * | 2000-02-25 | 2003-02-18 | Sun Microsystems, Inc. | Method and apparatus for post-mortem kernel memory leak detection |
US6697971B1 (en) * | 2000-10-24 | 2004-02-24 | Hewlett-Packard Development Company, L.P. | System and method for detecting attempts to access data residing outside of allocated memory |
FR2818770A1 (fr) * | 2000-12-21 | 2002-06-28 | Bull Cp8 | Procede de gestion optimisee de l'allocation de memoire d'un systeme embarque et systeme embarque correspondant |
US6681309B2 (en) * | 2002-01-25 | 2004-01-20 | Hewlett-Packard Development Company, L.P. | Method and apparatus for measuring and optimizing spatial segmentation of electronic storage workloads |
US8060680B2 (en) * | 2002-09-16 | 2011-11-15 | Hewlett-Packard Development Company, L.P. | Method of allocating memory |
US20040093537A1 (en) * | 2002-11-11 | 2004-05-13 | Thompson Ryan C. | System for determining computer program memory allocation and deallocation |
US7203720B2 (en) * | 2002-11-27 | 2007-04-10 | Bea Systems, Inc. | Web server hit multiplier and redirector |
US7096339B2 (en) * | 2003-03-01 | 2006-08-22 | International Business Machines Corporation | System and method for detecting memory management programming errors |
US20060095890A1 (en) * | 2004-11-01 | 2006-05-04 | Reeves Robert L | Embedded detection objects |
US7523450B2 (en) * | 2004-11-15 | 2009-04-21 | International Business Machines Corporation | Apparatus, system, and method for identifying fixed memory address errors in source code at build time |
US20060235655A1 (en) * | 2005-04-18 | 2006-10-19 | Qing Richard X | Method for monitoring function execution |
CN100407144C (zh) * | 2005-10-08 | 2008-07-30 | 腾讯科技(深圳)有限公司 | 一种启动应用程序中子模块的方法及装置 |
US7434105B1 (en) * | 2005-11-07 | 2008-10-07 | Symantec Operating Corporation | Selective self-healing of memory errors using allocation location information |
CN100419684C (zh) * | 2005-12-09 | 2008-09-17 | 腾讯科技(深圳)有限公司 | 为软件中的程序模块创建快捷方式及启动方法 |
US7730453B2 (en) * | 2005-12-13 | 2010-06-01 | Microsoft Corporation | Runtime detection for invalid use of zero-length memory allocations |
US7500079B2 (en) * | 2006-07-31 | 2009-03-03 | Microsoft Corporation | Detection of memory leaks |
US20080148102A1 (en) * | 2006-12-15 | 2008-06-19 | International Business Machines Corporation | Method for enhancing debugging of runtime memory access errors by using an integrated visualization tool and a runtime memory error detection tool |
US8086817B2 (en) * | 2006-12-21 | 2011-12-27 | International Business Machines Corporation | Method and system for efficient retrieval of data of large or unknown length by a native application program |
US7814288B2 (en) * | 2007-03-29 | 2010-10-12 | Microsoft Corporation | Protecting memory operations involving zero byte allocations |
GB2451253A (en) * | 2007-07-24 | 2009-01-28 | Ezurio Ltd | Indicating the position of a next declaration statement in object code when declaring a variable object code |
US7996648B2 (en) | 2007-12-19 | 2011-08-09 | Microsoft Corporation | Coupled symbiotic operating systems |
US8458514B2 (en) | 2010-12-10 | 2013-06-04 | Microsoft Corporation | Memory management to accommodate non-maskable failures |
US9785470B2 (en) * | 2011-06-20 | 2017-10-10 | Microsoft Technology Licensing, Llc | Memory management model and interface for unmodified applications |
US9619247B2 (en) | 2011-07-15 | 2017-04-11 | Microsoft Technology Licensing, Llc | Enabling fast string acquisition in an operating system for efficient interoperations with various language projections |
US8677189B2 (en) * | 2011-11-16 | 2014-03-18 | GM Global Technology Operations LLC | Recovering from stack corruption faults in embedded software systems |
CN102981919B (zh) * | 2012-11-02 | 2015-07-01 | 福建升腾资讯有限公司 | 快速定位错误源头的内存管理方法 |
CN103064754A (zh) * | 2012-11-14 | 2013-04-24 | 福建升腾资讯有限公司 | 快速定位错误源头的内存管理方法 |
Family Cites Families (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2757777B2 (ja) * | 1994-05-26 | 1998-05-25 | 住友金属工業株式会社 | メモリの不正アクセス検出方法及びシステム |
CA2136154C (en) * | 1994-11-18 | 1999-08-24 | Jay William Benayon | User control of multiple memory heaps |
EP0729097A1 (de) * | 1995-02-07 | 1996-08-28 | Sun Microsystems, Inc. | Verfahren und Vorrichtung zur Überwachung der Speicherzugriffe eines Vielfadenprogramms |
US5784699A (en) * | 1996-05-24 | 1998-07-21 | Oracle Corporation | Dynamic memory allocation in a computer using a bit map index |
US6058460A (en) * | 1996-06-28 | 2000-05-02 | Sun Microsystems, Inc. | Memory allocation in a multithreaded environment |
US5930829A (en) * | 1997-03-31 | 1999-07-27 | Bull Hn Information Systems Inc. | Dynamic memory allocation for a random access memory employing separately stored space allocation information using a tree structure |
-
1998
- 1998-09-24 WO PCT/GB1998/002883 patent/WO1999015965A1/en active IP Right Grant
- 1998-09-24 US US09/171,914 patent/US6363467B1/en not_active Expired - Fee Related
- 1998-09-24 EP EP98944100A patent/EP1015974B1/de not_active Expired - Lifetime
- 1998-09-24 DE DE69801332T patent/DE69801332T2/de not_active Expired - Fee Related
- 1998-09-24 AU AU91766/98A patent/AU9176698A/en not_active Abandoned
Also Published As
Publication number | Publication date |
---|---|
US20020035676A1 (en) | 2002-03-21 |
EP1015974B1 (de) | 2001-08-08 |
AU9176698A (en) | 1999-04-12 |
WO1999015965A1 (en) | 1999-04-01 |
US6363467B1 (en) | 2002-03-26 |
DE69801332D1 (de) | 2001-09-13 |
EP1015974A1 (de) | 2000-07-05 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
DE69801332T2 (de) | Speicherzuordnung | |
DE69232761T2 (de) | Verfahren und vorrichtung zur aenderung von dynamische zuweisbaren objektcodedateien | |
DE60130840T2 (de) | Vorrichtung und Verfahren zur Katalogisierung von symbolischen Daten zur Verwendung bei der Leistungsanalyse von Computerprogrammen | |
DE10050684B4 (de) | Verfahren und System zur periodischen Ablaufverfolgung für Aufrufsequenzen zwischen Routinen | |
DE69625636T2 (de) | System und Verfahren zum Steuern und Verwalten von verteilten Objektservern unter Verwendung von erstklassigen verteilten Objekten | |
DE69932371T2 (de) | Verschiebbare Instrumentationskennzeichen für die Prüfung und die Fehlerbeseitigung eines Computerprogramms | |
DE69919632T2 (de) | Fehlertoleranz durch N-modulare Softwareredundanz unter Verwendung von indirekter Instrumentierung | |
DE69803624T2 (de) | Verfahren und Vorrichtung zur generationellen Freispeichersammlung in einem gemeinsam verwendeten Heapspeicher mittels mehrerer Prozessoreinheiten | |
DE60032685T2 (de) | Speicherrückforderungsverfahren | |
DE69216020T2 (de) | Verbessertes fehlersuchsystem und -verfahren, besonders für die fehlersuche in einer multi-architekturumgebung | |
DE69909945T2 (de) | Verfahren und Anordnung zur Korrelation von Profildaten dynamisch erzeugt durch ein optimiertes ausführbares Programm mit Quellcodeanweisungen | |
DE60010420T2 (de) | Automatisches Regressionstesten von Arbeitsplatz-Software | |
DE69328665T2 (de) | Gerät zur Auflösung von Datenreferenzen in erzeugtem Kode | |
DE69510801T2 (de) | Verfahren und vorrichtung zur modellierung von rechnerprozessbetriebsmitteln | |
DE60001916T2 (de) | Plattformunabhängige speicherabbild analysearchitektur zur programmfehlerbeseitigung | |
US6658653B1 (en) | Debugging methods for heap misuse | |
DE69918334T2 (de) | Erzeugung von kompilierten programmen für interpretative laufzeitumgebungen | |
DE102007025397B4 (de) | System mit mehreren Prozessoren und Verfahren zu seinem Betrieb | |
DE69618221T2 (de) | Mechanismus zur wartung objektorientierter "methoden" der keine unterbrechung des computersystems erfordert | |
DE10335989B4 (de) | Online-Änderungen von CIL-Code-Programmen für die Industrieautomatisierung | |
DE3842289C2 (de) | Verfahren zur Entwicklung von Programmen für ein verteiltes Datenverarbeitungssystem | |
DE10225664A1 (de) | System und Verfahren zum Prüfen von Systemabrufereignissen mit Systemabrufumhüllungen | |
DE112019001821B4 (de) | Verfahren und vorrichtung zur wiedergabe eines aktivierungsrahmens für unterbrechungsfreie speicherbereinigung (pause-less garbage collection) | |
DE69931685T2 (de) | Verfahren und Gerät zum Implementieren von schnellen Subclass- und Subtyp-Überprüfungen | |
DE69636141T2 (de) | Rechnerimplementiertes Verfahren zur Bestimmung eines Minimalcodesets für ein ausführbares Programm in einem Datenverarbeitungssystem |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
8364 | No opposition during term of opposition | ||
8339 | Ceased/non-payment of the annual fee |