DE69801332T2 - Speicherzuordnung - Google Patents

Speicherzuordnung

Info

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
Application number
DE69801332T
Other languages
English (en)
Other versions
DE69801332D1 (de
Inventor
Richard Weeks
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
British Telecommunications PLC
Original Assignee
British Telecommunications PLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from GBGB9720460.6A external-priority patent/GB9720460D0/en
Application filed by British Telecommunications PLC filed Critical British Telecommunications PLC
Application granted granted Critical
Publication of DE69801332D1 publication Critical patent/DE69801332D1/de
Publication of DE69801332T2 publication Critical patent/DE69801332T2/de
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/362Software debugging
    • G06F11/366Software debugging using diagnostics
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02Addressing or allocation; Relocation
    • G06F12/0223User address space allocation, e.g. contiguous or non contiguous base addressing
    • G06F12/023Free address space management
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00Accessing, addressing or allocating within memory systems or architectures
    • G06F12/14Protection against unauthorised use of memory or access to memory
    • G06F12/1416Protection 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/1425Protection 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
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/10Providing a specific technical effect
    • G06F2212/1052Security 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.
DE69801332T 1997-09-25 1998-09-24 Speicherzuordnung Expired - Fee Related DE69801332T2 (de)

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)

* Cited by examiner, † Cited by third party
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)

* Cited by examiner, † Cited by third party
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

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