DE10240883A1 - Verfahren zum Erfassen eines unbegrenzten Wachstums verketteter Listen in einer laufenden Anwendung - Google Patents

Verfahren zum Erfassen eines unbegrenzten Wachstums verketteter Listen in einer laufenden Anwendung

Info

Publication number
DE10240883A1
DE10240883A1 DE10240883A DE10240883A DE10240883A1 DE 10240883 A1 DE10240883 A1 DE 10240883A1 DE 10240883 A DE10240883 A DE 10240883A DE 10240883 A DE10240883 A DE 10240883A DE 10240883 A1 DE10240883 A1 DE 10240883A1
Authority
DE
Germany
Prior art keywords
linked list
size
predetermined period
program
maximum size
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.)
Withdrawn
Application number
DE10240883A
Other languages
English (en)
Inventor
James R Curtis
Eric Hwang
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.)
Hewlett Packard Development Co LP
Original Assignee
Hewlett Packard Co
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
Application filed by Hewlett Packard Co filed Critical Hewlett Packard Co
Publication of DE10240883A1 publication Critical patent/DE10240883A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • 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
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0751Error or fault detection not based on redundancy
    • G06F11/0754Error or fault detection not based on redundancy by exceeding limits
    • G06F11/076Error or fault detection not based on redundancy by exceeding limits by exceeding a count or rate limit, e.g. word- or bit count limit
    • 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
    • G06F12/0253Garbage collection, i.e. reclamation of unreferenced memory

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Debugging And Monitoring (AREA)

Abstract

Ein Verfahren zum Erfassen eines Speicherlecks einer verketteten Liste in einem laufenden Programm umfaßt ein Speichern der gegenwärtigen Größe der verketteten Liste als eine neue maximale Größe der verketteten Liste, wenn ein neues Element zu der verketteten Liste hinzugefügt wird, das bewirkt, daß die gegenwärtige Größe der verketteten Liste eine frühere maximale Größe der verketteten Liste überschreitet, ein Bestimmen, ob ein erster vorbestimmter Zeitraum von dem Zeitpunkt an verstrichen ist, zu dem die verkettete Liste erzeugt wurde, und ein Bestimmen, ob die neue maximale Größe der verketteten Liste die frühere maximale Größe der verketteten Liste während eines zweiten vorbestimmten Zeitraums überschreitet.

Description

  • Diese Erfindung bezieht sich allgemein auf einen Fehlersuch-Programmcode und spezieller auf Verfahren und Vorrichtungen zum Erfassen eines Speicherlecks bei verketteten Listen, die in einem laufenden Programm enthalten sind.
  • Ein häufiges Problem bei der Softwareentwicklung sind Speicherlecks. Ein Speicherleck tritt auf, wenn ein Programm oder eine Anwendung ein Stück Speicher in einem Programmhaufen reserviert (abhängig von der Programmsprache allgemein durch intrinsische Aufrufe malloc() oder new()), die Tatsache aus den Augen verliert, daß das Programm dieses Stück Speicher reserviert hat und das reservierte Stück Speicher niemals frei macht. Wenn das Programm reservierten Speicher während der Ausführung des Programms nicht ausreichend oft ordnungsgemäß freigibt, wächst die Programmiersprache hinsichtlich der Speichergröße weiter und stirbt schließlich, wenn das System keinen Speicher mehr hat, den es dem laufenden Programm geben kann. Dieser Typ von Programmfehler ist als "Speicherleck" bekannt.
  • Es gibt mehrere verfügbare Tools, wie z. B. Insure™ (von Parasoft) und Purify™ (von Rational Software), die gemeinsam mit einem Programm betrieben werden können, um zu bestimmen, ob das Programm Speicherlecks aufweist. Diese Tools sehen nach Fällen, in denen ein Stück Speicher innerhalb einer Funktion einer lokalen Zeigervariable zugewiesen ist. Wenn dieses gleiche Stück Speicher anderen Variablen zugewiesen ist, wird eine Referenzzählung aufrechterhalten und eine Datenbank mit dem Ort in dem Quellencode des Programms aktualisiert, an dem jede Referenz auftritt. Wenn eine Variable, die eine Referenz auf das Stück Speicher aufweist, entweder erneut zugewiesen wird oder aufgrund einer Funktionsrückkehr nicht mehr in dem Bereich ist, wird die Referenzzählung des Stücks Speicher geprüft, um sicherzustellen, daß eine andere Variable weiterhin eine Referenz auf dieses Stück Speicher hat.
  • Der Programmierer muß explizit einen Code in das Programm einschließen, um das Stück Speicher (oft durch intrinsisches Aufrufen free()) zu befreien, wenn das Programm mit dem Stück Speicher fertig ist. Sobald das Stück Speicher befreit wurde, wird das Stück Speicher dem Programmhaufen zur Wiederverwendung durch das Programm zurückgegeben. Wenn es jedoch keine Variablen mehr gibt, die auf das Stück Speicher verweisen, und das Stück Speicher nicht explizit befreit wurde, geht man davon aus, daß das Stück Speicher leck ist. Tools, wie z. B. Insure™ und Purify™, berichten das Leck, wodurch es dem Programmierer ermöglicht wird, das Leck zu verfolgen und das Problem zu beheben.
  • Es gibt jedoch eine andere Art von Leck, die Tools, wie z. B. Insure™ und Purify™, nicht finden können. Dies sind Lecks, die in verketteten Listen auftreten. Heute verwenden die meisten Programme Datenstrukturen mit verketteten Listen. Eine verkettete Liste ist eine Datenstruktur, die es ermöglicht, daß neue Elemente zu der existierenden Liste hinzugefügt und mit derselben verkettet werden. Warteschlangen und Stapel sind häufige Verwendungen für verkettete Listen, Datenbanken können jedoch auch unter Verwendung mehrerer verketteter Listen implementiert sein. Ein Dateisystem kann unter Umständen auch verkettete Listen verwenden, indem es die verketteten Listen auf eine hierarchische Weise verwendet. Verkettete Listen enthalten einen Kopfzeiger, der auf das erste (oder letzte) Element in den verketteten Listen verweist. Verkettete Elemente enthalten auch "Nächstes"-Zeiger, die auf das nächste Element in der Liste verweisen.
  • Das Problem bei der Verwendung von Tools, wie z. B. Insure™ und Purify™, um Lecks in verketteten Listen zu finden, besteht darin, daß diese Tools nicht mit Situationen zurecht kommen, in denen es noch immer eine bestimmte Referenz auf den Speicher gibt, wie dies bei verketteten Listen der Fall ist. Solange es eine Referenz auf den Kopfzeiger gibt, gibt es eine Referenz auf die gesamte verkettete Liste und Speicherleck-Tools, wie z. B. Insure™ und Purify™, betrachten kein Element in der Liste als "leck". Wenn der Code des Programms jedoch weiterhin Elemente zu der verketteten Liste hinzufügt, ohne dieselben explizit zu entfernen, nachdem diese nicht weiter benötigt werden, hat die verkettete Liste schließlich ein Leck.
  • Es ist die Aufgabe der vorliegenden Erfindung, ein Verfahren, ein computerlesbares Medium oder ein System zu schaffen, die ein Speicherleck in einer verketteten Liste erfassen, auch wenn noch immer durch eine bestimmte Variable in dem laufenden Programm auf das lecke Stück Speicher verwiesen wird.
  • Diese Aufgabe wird durch ein Verfahren gemäß Anspruch 1, ein computerlesbares Medium gemäß Anspruch 6 oder ein System gemäß Anspruch 11 gelöst.
  • Das hierin beschriebene Verfahren und System sind dahingehend von Vorteil, daß sie die obigen Probleme überwinden, indem sie ein Speicherleck in einer verketteten Liste erfassen, auch wenn noch immer durch eine bestimmte Variable in einem laufenden Programm auf die verkettete Liste verwiesen wird. Ein weiterer Vorteil des hierin beschriebenen Verfahrens und des Systems besteht darin, daß das Wachstum der verketteten Liste über ein Maximum, eine frühere maximale Größe, hinaus verfolgt wird, wodurch es einem Programmentwickler ermöglicht wird, genau zu bestimmen, ob die verkettete Liste ein Speicherleck aufweist.
  • Diese und weitere Vorteile werden bei einem System zum Erfassen eines Speicherlecks einer verketteten Liste in einem laufenden Programm erzielt, das einen Prozessor, eine Ausgabevorrichtung und einen Speicher umfaßt. Der Speicher speichert einen Programmcode des laufenden Programms und Module, die den Prozessor steuern. Ein Modul speichert eine gegenwärtige Größe der verketteten Liste während eines ersten vorbestimmten Zeitraums als eine neue maximale Größe der verketteten Liste, wenn ein neues Element zu der verketteten Liste hinzugefügt wird, das bewirkt, daß die gegenwärtige Größe der verketteten Liste eine frühere maximale Größe der verketteten Liste überschreitet. Ein weiteres Modul bestimmt, ob ein erster vorbestimmter Zeitraum von dem Zeitpunkt an verstrichen ist, zu dem die verkettete Liste erzeugt wurde, wenn die gegenwärtige Größe der verketteten Liste die frühere maximale Größe der verketteten Liste überschreitet. Sobald der erste vorbestimmte Zeitraum verstrichen ist, erreicht die verkettete Liste einen stabilen Zustand, über den hinaus dieselbe nicht anwachsen sollte. Ein zusätzliches Modul bestimmt, ob die neue maximale Größe der verketteten Liste die frühere maximale Größe während eines zweiten vorbestimmten Zeitraums überschreitet. Der zweite vorbestimmte Zeitraum erstreckt sich vorzugsweise über das Ende des ersten vorbestimmten Zeitraums hinaus. Der Prozessor führt das laufende Programm aus und führt die Module zum Erfassen eines Speicherlecks verketteter Listen aus, die in dem laufenden Programm enthalten sind. Die Ausgabevorrichtung zeigt einen Bericht an, wenn die neue maximale Größe der verketteten Liste die frühere Maximalgröße der verketteten Liste überschreitet.
  • Diese und weitere Vorteile werden außerdem durch ein Verfahren zum Erfassen eines Speicherlecks einer verketteten Liste in einem laufenden Programm erzielt, das ein Speichern einer gegenwärtigen Größe der verketteten Liste während eines ersten vorbestimmten Zeitraums als eine neue maximale Größe der verketteten Liste, wenn ein neues Element zu der verketteten Liste hinzugefügt wird, das bewirkt, daß die gegenwärtige Größe der verketteten Liste eine frühere maximale Größe der verketteten Liste überschreitet, umfaßt. Das Verfahren umfaßt außerdem ein Bestimmen, ob ein erster vorbestimmter Zeitraum von dem Zeitpunkt an verstrichen ist, zu dem die verkettete Liste erzeugt wurde, wenn die gegenwärtige Größe der verketteten Liste die frühere maximale Größe der verketteten Liste überschreitet. Sobald der erste vorbestimmte Zeitraum verstrichen ist, erreicht die verkettete Liste einen stabilen Zustand, über den hinaus dieselbe nicht anwachsen sollte. Das Verfahren umfaßt zusätzlich ein Bestimmen, ob die neue maximale Größe der verketteten Liste die frühere maximale Größe währehd eines zweiten vorbestimmten Zeitraums überschreitet. Der zweite vorbestimmte Zeitraum erstreckt sich vorzugsweise über das Ende des ersten vorbestimmten Zeitraums hinaus.
  • Bevorzugte Ausführungsbeispiele der vorliegenden Erfindung werden nachfolgend Bezug nehmend auf die beigefügten Zeichnungen näher erläutert, in denen gleiche Bezugszeichen sich auf gleiche Elemente beziehen. Es zeigen:
  • Fig. 1 ein Blockdiagramm eines bevorzugten Ausführungsbeispiels eines Computersystems zum Implementieren der vorliegenden Erfindung;
  • Fig. 2 ein Flußdiagramm eines bevorzugten Verfahrens zum Erfassen eines Speicherlecks in verketteten Listen in laufenden Programmen durch eine Belastungsprüfung;
  • Fig. 3 ein Flußdiagramm eines bevorzugten Verfahrens, das nach einer Erfassung der Erzeugung einer verketteten Liste in einem laufenden Programm durchgeführt wird;
  • Fig. 4 ein Flußdiagramm eines bevorzugten Verfahrens zum Prüfen auf Speicherlecks einer verketteten Liste in laufenden Programmen; und
  • Fig. 5 ein Flußdiagramm eines bevorzugten Verfahrens zum Berichten eines möglichen Speicherlecks in einer stabilen verketteten Liste.
  • Fig. 1 ist ein Blockdiagramm, das ein bevorzugtes Ausführungsbeispiel eines Computersystems 10 darstellt, bei dem das hierin beschriebene Verfahren implementiert sein kann. Das Computersystem 10 umfaßt üblicherweise einen Speicher 20, eine Ausgabevorrichtung 24, eine Anzeigevorrichtung 26, eine sekundäre Speichervorrichtung 28, einen Prozessor 34 und eine Eingabevorrichtung 36. Der Speicher 20 kann einen Direktzugriffsspeicher (RAM) oder ähnliche Typen von Speicher umfassen. Die sekundäre Speichervorrichtung 28 kann ein Festplattenlaufwerk, ein Diskettenlaufwerk, ein CDROM- Laufwerk oder andere Typen von nicht-flüchtigen Datenspeicherungen umfassen. Die sekundäre Speichervorrichtung 28 kann außerdem gemäß dem hierin beschriebenen Verfahren eines oder mehrere Programme 30 speichern, die gerade entwickelt werden, und die vorzugsweise Module beinhalten, die Instruktionen zur Speicherleckerfassung 32 enthalten. Alternativ können das oder die Programme 30 und die Module zur Speicherleckerfassung 32 in dem Speicher 20 gespeichert sein.
  • Der Prozessor 34 führt ein Programm aus, das aus dem oder den Programmen 30 und den Modulen 32, die in dem Speicher 20 oder der sekundären Speichervorrichtung 50 gespeichert sind, ausgewählt wird. Die Eingabevorrichtung 36 kann jede Vorrichtung zum Eingeben von Informationen in das Computersystem 10 umfassen, wie z. B. eine Tastatur, eine Maus, eine Cursorsteuerungsvorrichtung, einen Berührungsbildschirm, eine Infrarotvorrichtung, ein Mikrophon, eine Digitalkamera, einen Videorekorder oder einen Camcorder. Die Anzeigevorrichtung 26 kann jeden Typ von Vorrichtung zum Darstellen visueller Informationen umfassen, wie z. B. einen Computerbildschirm oder eine Flachbildschirmanzeige. Die Ausgabevorrichtung 24 kann jeden Typ von Vorrichtung zum Darstellen einer Druckkopie von Informationen, wie z. B. einen Drucker, und andere Typen von Ausgangsvorrichtungen, die Lautsprecher umfassen, oder jede Vorrichtung zum Bereitstellen von Informationen in einer Audioform umfassen.
  • Das Computersystem 10 kann jeder Typ von Benutzermaschine zum Ausführen des oder der Programme 30 und der Module zur Speicherleckerfassung 32 sein, einschließlich Personalcomputern, Laptop-Computern, Notebook-Computern, Palmtop- Computern, Netzcomputern oder jeder prozessorgesteuerten Vorrichtung, die in der Lage ist, das oder die Programme 30 und die Module zur Speicherleckerfassung 32 auszuführen.
  • Fig. 2 ist ein Flußdiagramm eines bevorzugten Verfahrens zum Erfassen eines Speicherlecks in verketteten Listen in laufenden Programmen durch eine Belastungsprüfung, wobei das Verfahren allgemein durch das Bezugszeichen 100 bezeichnet ist. Das Speicherleckerfassungsverfahren 100 umfaßt einen Schritt 110 eines Einleitens einer Belastungsprüfung eines Programms 30, das gerade entwickelt wird, einen Schritt 120 eines Erfassens der Erzeugung einer verketteten Liste in dem Programm 30, das gerade entwickelt wird, und einen Schritt 130 eines Bestimmens, ob ein Element zu der verketteten Liste hinzugefügt wurde. Das Verfahren 100 umfaßt außerdem einen Schritt 135 eines Ausführens eines Algorithmus 135 zur Wachstumsprüfung der verketteten Liste (Linked List Check Growth Algorithm), wenn ein neues Element hinzugefügt wurde, einen Schritt 140 eines Bestimmens, ob eine Dauer der Belastungsprüfung des Programms 30 verstrichen ist, und einen Schritt 150 eines Beendens der Belastungsprüfung des Programms 30 und eines Beendens des Algorithmus zur Wachstumsprüfung der verketteten Liste, wenn die Dauer der Belastungsprüfung verstrichen ist.
  • Das Einleiten einer Belastungsprüfung des Programms 30, das gerade entwickelt wird, bei Schritt 110 umfaßt vorzugsweise ein Durchführen einer Belastungsprüfung hinsichtlich des Programms, derart, daß eine reale Langzeitverwendung des Programms 30 in einem kurzen Zeitraum, z. B. ein paar Stunden, simuliert werden kann. Eine Belastungsprüfung beinhaltet ein Erdrücken des Programms 30 mit Befehlen. Wenn z. B. das Programm 30 eine Art von Benutzerschnittstelle aufweist und Benutzerbefehle benötigt, um zu wirken, würde die Belastungsprüfung beinhalten, daß das Programm 30 eine große Anzahl von Benutzerbefehlen sehr schnell über einen langen Zeitraum, z. B. 24 Stunden, ausführen muß. Durch ein Durchführen dieser Art von Belastungsprüfung kann ein Programmentwickler z. B. 150 Jahre einer Benutzungsumgebungsausführung in einer kurzen Zeitmenge simulieren.
  • Der Code, der das Programm 30 implementiert, umfaßt einen Algorithmus zur Wachstumsprüfung der verketteten Liste, der ein exemplarisches Stück Code ist, der in dem Programm 30, das gerade entwickelt wird, kompiliert wird, der die Module zur Speicherleckerfassung 32 implementiert, wie in Fig. 1 ersichtlich ist. Der Programmcode 30 ist vorzugsweise mit dem Algorithmus versehen, um es dem Programmentwickler zu ermöglichen, Speicherlecks zu erfassen. Bei einem bevorzugten Ausführungsbeispiel umfaßt das Programm 30, das gerade entwickelt wird, den Algorithmusimplementierungscode nur, während das Programm 30 entwickelt wird. Der Implementierungscode für den Algorithmus wird vorzugsweise aus dem Programm 30 entfernt, sobald das Programm 30 bereit zur Verwendung in einer Kundenumgebung ist. Ein exemplarischer C-Code, der den Algorithmus der Wachstumsprüfung der verketteten Liste implementiert, ist wie folgt:






  • Das Erfassen, bei Schritt 120, der Erzeugung einer verketteten Liste umfaßt vorzugsweise, daß der Algorithmus zur Wachstumsprüfung der verketteten Liste die Programmsprache in dem Code des laufenden Programms 30 benachrichtigt, der eine verkettete Liste erzeugt. Der spezifische Programmierungscode, der verwendet wird, um eine verkettete Liste in dem ausgeführten Programm 30 zu erzeugen, hängt natürlich von der Programmiersprache ab, in der das Programm 30 geschrieben ist. Wenn eine verkettete Liste erzeugt wird, wird ebenfalls ein Kopfzeiger für diese verkettete Liste erzeugt. Der Kopfzeiger zeigt den Ort des Anfangs der Struktur der verketteten Liste an, den "Kopf" der Kette von Speicherorten, die identifiziert sind, um zu der verketteten Liste zu gehören. Im Gegensatz dazu zeigen Nächstes- Zeiger von jedem verketteten Element in der Kette auf das nächste verkettete Element, wobei der Nächstes-Zeiger in der letzten Speicherverbindung auf einen NULL-Wert zeigt.
  • Die Datenstruktur des Kopfzeigers enthält vorzugsweise mehrere Stücke von Informationen hinsichtlich der verketteten Liste, auf die derselbe verweist. Der Kopfzeiger enthält ein Gegenwärtige-Größe-Feld, das anzeigt, wie viele Elemente gegenwärtig in der verketteten Liste sind. Jedesmal, wenn ein Element zu der verketteten Liste hinzugefügt wird, wird das Gegenwärtige-Größe-Feld inkrementiert und jedesmal, wenn ein Element freigegeben oder entfernt wird, wird das Gegenwärtige-Größe-Feld dekrementiert. Die Datenstruktur des Kopfzeigers enthält außerdem ein Feld, das eine gegenwärtige Hochwassergröße oder -zählung der verketteten Liste anzeigt. Das Hochwasserzählungsfeld verfolgt die größte Größe, die die verkettete Liste jemals erreicht hat. Jedesmal, wenn die Größe der verketteten Liste größer als die Hochwasserzählung wird, wird die Hochwasserzählung eingestellt, um an die neue größte Größe angepaßt zu sein.
  • Die Datenstruktur des Kopfzeigers kann auch ein Namenfeld enthalten. Wenn das Programm 30 eine neue verkettete Liste initialisiert, kann das Programm 30 einen Namen der verketteten Liste als einen Parameter gegenüber der Routine spezifizieren, die die verkettete Liste erzeugt, wobei der Name in der Datenstruktur des Kopfzeigers gespeichert wird. Das Namenfeld ist ein Zeichenfolgentyp dessen, welche Länge auch immer es ermöglicht, daß die verkettete Liste eindeutig unter allen verketteten Listen, die in dem laufenden Programm 30 existieren können, identifiziert wird. Der Name der verketteten Liste wird in dem Nachrichtenprotokoll angezeigt, um dem Programmentwickler zu helfen zu entdecken, welche verkettete Liste eines Speicherlecks verdächtig ist.
  • Die letzten beiden Felder in der Datenstruktur des Kopfzeigers sind zeitbezogene Felder. Ein Erzeugungszeit-Feld zeigt an, wann die verkettete Liste erzeugt wurde. Wenn das Programm 30 die verkettete Liste initialisiert, wird ein Systemtakt (nicht gezeigt) des Computersystems 10 abgefragt, wobei das Ergebnis in dem Erzeugungszeit-Feld gespeichert wird. Ein Letzte-Hochwasser-Anstiegszeit-Feld wird basierend auf einer Abfrage hinsichtlich des Systemtaktes jedesmal aktualisiert, wenn die Hochwasserzählung der verketteten Liste ansteigt. Der Schritt des Erfassen, bei 130, der Erzeugung einer verketteten Liste wird weiter unten Bezug nehmend auf Fig. 3 detaillierter beschrieben.
  • Das Bestimmen, bei Schritt 130, ob ein Element zu der verketteten Liste hinzugefügt wurde, umfaßt vorzugsweise ein Lesen des Gegenwärtige-Größe-Feldes und ein Prüfen, ob die gegenwärtige Größe der verketteten Liste angestiegen ist. Wenn kein Element zu der verketteten Liste hinzugefügt wurde, fährt das Speicherleckerfassungsverfahren 100 mit dem Überwachen der verketteten Liste nach hinzugefügten Elementen fort, bis die verkettete Liste entweder durch einen geeigneten Programmcode zerstört wird oder die Belastungsprüfung des Programms 30, das gerade entwickelt wird, zu Ende ist. Wenn ein Element hinzugefügt wurde, wird der Algorithmus der Wachstumsprüfung der verketteten Liste bei einem Schritt 135 ausgeführt, um die verkettete Liste nach möglichen Speicherlecks zu überwachen.
  • Das Überwachen verketteter Listen nach Speicherlecks unter Verwendung des Algorithmus der Wachstumsprüfung der verketteten Liste umfaßt ein Verfahren zum Prüfen dessen, ob ein bestimmter Typ verketteter Liste, die in dem Programm 30 erzeugt wird, über eine stabile Größe hinaus wächst. Ein derartiges Wachstum zeigt ein Speicherleck in der/den verketteten Listen an. Der Algorithmus zur Wachstumsprüfung der verketteten Liste wird jedesmal ausgelöst, wenn ein neues Element zu einer existierenden verketteten Liste in dem Programm 30 hinzugefügt wird. Der Programmcode 30, der das neue Element zu der verketteten Liste hinzugefügt hat, ruft den Algorithmus zur Wachstumsprüfung der verketteten Liste auf, nachdem derselbe das neue Element zu der verketteten Liste hinzugefügt und das Gegenwärtige-Größe-Feld in der Datenstruktur des Kopfzeigers aktualisiert hat. Deshalb wirkt der Algorithmus zur Wachstumsprüfung der verketteten Liste wie eine Programmunterbrechung, die aufgerufen wird, wenn ein neues Element zu einer existierenden verketteten Liste hinzugefügt wird, und kehrt zu dem laufenden Programm 30 zurück, wenn er fertig ausgeführt ist.
  • Der Typ verketteter Listen, die bedenkliche Speicherlecks aufweisen können, sind langlebige verkettete Listen. Langlebige verkettete Listen sind verkettete Listen, die über die gesamte Lebensdauer des laufenden Programmes 30 existieren. Ein Beispiel einer derartigen langlebigen verketteten Liste ist eine Serie verketteter Listen, die verwendet werden, um eine speicherinterne Datenbank in dem Programm 30 zu implementieren. Oft beinhaltet die Implementierung einer Datenbank eine Serie von Tabellen. Diese Tabellen werden üblicherweise über verkettete Listen implementiert, wobei die Aufzeichnungen (oder Reihen) in der Tabelle Elemente in einer verketteten Liste sind. Zu Zwecken eines Testens kann eine verkettete Liste als langlebig betrachtet werden, wenn sie noch immer existiert, nachdem eine bestimmte vorbestimmte langlebige Zeitgrenze seit dem Zeitpunkt verstrichen ist, zu dem die verkettete Liste erzeugt wurde. Die langlebige Zeitgrenze ist eine Schwelle dessen, wie lang eine verkettete Liste existieren muß, nachdem sie erzeugt wurde, um als langlebig betrachtet zu werden. Der Programmentwickler kann z. B. entscheiden, daß in einer Belastungsprüfungsumgebung jede verkettete Liste, die zwei Stunden oder mehr, nachdem sie erzeugt wurde, noch existiert, eine langlebige verkettete Liste ist.
  • Langlebige verkettete Listen stehen im Gegensatz zu kurzlebigen verketteten Listen, die z. B. nur einige Sekunden lang existieren können, während das Programm ausgeführt wird. Da kurzlebige verkettete Listen sehr transient sind, sind sie nicht von Belang, da dieselben üblicherweise nicht ausreichend lange vorhanden sind, um ein Speicherleck aufzuweisen, das die Speicherreserven des Computersystems vollständig aufzehren könnte. Langlebige verkettete Listen andererseits erreichen schließlich einen stabilen Zustand oder eine stabile Größe, über die hinaus dieselben erwartungsgemäß nicht wachsen sollten, da erzeugten verketteten Elementen durch freigegebene verkettete Elemente entgegengewirkt wird. Deshalb ist es, wenn eine stabile langlebige verkettete Liste über ihre stabile Größe hinaus wächst, wahrscheinlich, daß die verkettete Liste ein Speicherleck aufweist.
  • Wenn ein derartiges Wachstum erfaßt wird, kann ein Bericht, der vorzugsweise den Namen der verketteten Liste umfaßt, die verdächtigt wird, ein Speicherleck aufzuweisen, sowie eine Stapelspur dessen, welcher Programmcode beim Anwachsen der verketteten Liste beinhaltet war, in einem Nachrichtenprotokoll oder durch eine andere Berichteinrichtung, wie z. B. eine Anzeige auf einem Computermonitor, zur Durchsicht durch den Programmentwickler gedruckt werden. Das Nachrichtenprotokoll, das durch den Algorithmus zur Wachstumsprüfung der verketteten Liste erzeugt wird, liefert derartige Informationen wie eine Zeit, zu der die verdächtige verkettete Liste erzeugt wurde, die Dauer, wie lange die verdächtige verkettete Liste bereits existiert, eine Zeit, zu der die verdächtige verkettete Liste zuletzt größenmäßig zugenommen hat, und eine gegenwärtige Größe der verdächtigen verketteten Liste.
  • Es wird angemerkt, daß der Algorithmus zur Wachstumsprüfung der verketteten Liste ausgelöst wird, wenn eine verkettete Liste, die bereits in dem Programm 30 existiert, ihre Größe erhöht. Üblicherweise überwacht der Algorithmus zur Wachstumsprüfung der verketteten Liste gleichzeitig mehrere verkettete Listen. Zur Einfachheit betrachtet diese Beschreibung jedoch nur eine Überwachung einer einzelnen verketteten Liste. Ein bevorzugtes Verfahren zum Ausführen, bei Schritt 135, des Algorithmus zur Wachstumsprüfung der verketteten Liste wird unten Bezug nehmend auf Fig. 4 detaillierter beschrieben.
  • Der Schritt des Bestimmens, bei 140, ob die Dauer der Belastungsprüfung des Programms 30 verstrichen ist, beinhaltet ein Abfragen des Systemtaktes, um zu bestimmen, ob eine vorbestimmte Zeitdauer seit einem Zeitpunkt verstrichen ist, zu dem die Belastungsprüfung begann. Die Dauer der Belastungsprüfung wird durch den Programmentwickler oder durch wen auch immer gesetzt, der die Belastungsprüfung durchführen kann. Der Programmentwickler wählt die Dauer der Belastungsprüfung derart, daß er überzeugt ist, daß alle möglichen Speicherlecks lokalisiert werden, und daß alle anderen Programmprobleme während der Belastungsprüfung behandelt werden. Wenn die Dauer der Belastungsprüfung nicht verstrichen ist, fährt das Speicherleckerfassungsverfahren 100 fort, um alle Größenanstiege in den verketteten Listen im Programm 30 zu überwachen (Schritt 130). Wenn die Dauer der Belastungsprüfung verstrichen ist, wird die Belastungsprüfung durch ein Anhalten der Ausführung des Programms 30, das getestet wird, und ein Beenden der Ausführung des Algorithmus zur Wachstumsprüfung der verketteten Liste bei Schritt 150 beendet.
  • Sobald die Belastungsprüfung des Programms 30, das gerade entwickelt wird, zu Ende ist, und der Algorithmus zur Wachstumsprüfung der verketteten Liste Berichte hinsichtlich der Möglichkeit eines Speicherlecks in verschiedenen verketteten Listen erzeugt hat, sieht der Programmentwickler das Nachrichtenprotokoll durch, das den Namen der erwarteten verketteten Liste/n und die darauf bezogene/n Stapelspur/en enthält. Der Programmentwickler prüft das Nachrichtenprotokoll und sucht nach Fällen, in denen eine stabile verkettete Liste größenmäßig über ihre stabile Größe hinaus wuchs. Der Programmentwickler sieht dann die Stapelspur des Codes, der in dem Nachrichtenprotokoll berichtet wurde, nach einem Code durch, der die Größe der verketteten Liste erhöht hat, und sieht nach, wo der Fehler auftrat, der das Speicherleck bewirkt hat.
  • Das Nachrichtenprotokoll berichtet auch die Zeitmenge, die zwischen Wachstumsinstanzen in der verketteten Liste vergangen ist. Die Zeit zwischen Wachstumsinstanzen ist außerdem ein Indikator dessen, ob es ein Speicherleck der verketteten Liste gibt. Wenn die Zeit zwischen Wachstumsinstanzen in der Größenordnung einiger Minuten ist, ist dies z. B. eine gute Anzeige, daß es ein Speicherleck gibt. Wenn die Zeit zwischen Wachstumsinstanzen in der Größenordnung von Sekunden ist, ist die Wahrscheinlichkeit, daß es ein Speicherleck gibt, größer, da eine derartig kurze Zeitdauer ein unkontrolliertes Wachstum der verketteten Liste anzeigt. Wenn die Zeit zwischen Wachstumsinstanzen z. B. 5 oder 10 Minuten oder länger ist, zeigt dies an, daß das Speicherleck wahrscheinlich kein Problem ist. Derartig lange Dauern zwischen Wachstumsinstanzen zeigen wahrscheinlicher ein normales Funktionieren des Programms 30 an. Gleichermaßen ist ein Speicherleck weniger wahrscheinlich, wenn die verkettete Liste größenmäßig nur ein paarmal ansteigt, nachdem sie einen stabilen Zustand erreicht, wohingegen ein Speicherleck wahrscheinlicher ist, wenn die stabile verkettete Liste wesentlich über ihren stabilen Zustand hinaus wächst. Sobald der Programmentwickler bestimmt hat, daß eine bestimmte verkettete Liste ein Speicherleck aufweist, kann der Programmentwickler den Programmcode des Programms 30, das gerade entwickelt wird, bearbeiten, um den Fehler zu beheben.
  • Fig. 3 ist ein Flußdiagramm eines Verfahrens, das nach einem Erfassen der Erzeugung einer verketteten Liste in einem laufenden Programm durchgeführt wird, das allgemein durch das Bezugszeichen 120 bezeichnet ist. Sobald die Programmsprache in dem Code des laufenden Programms 30 eine verkettete Liste erzeugt, wird eine Zeit der Erzeugung sowie die Größe der verketteten Liste in der Datenstruktur des Kopfzeigers gespeichert, die erzeugt wird, wenn die verkettete Liste erzeugt wird. Das Erfassungsverfahren 120 umfaßt ein Speichern einer Erzeugungszeit der verketteten Liste und ein Speichern einer anfänglichen Hochwasserzählung der verketteten Liste.
  • Das Speichern, bei Schritt 200, der Erzeugungszeit umfaßt ein Lesen des Systemtaktes in dem Computersystem 10 und ein Einstellen eines Wertes in dem Erzeugungs-Feld der Datenstruktur des Kopfzeigers gleich dem der gegenwärtigen Zeit. Die Erzeugungszeit der verketteten Liste ist der Referenzpunkt, von dem aus bestimmt wird, ob die verkettete Liste stabil geworden ist oder nicht.
  • Das Speichern, bei Schritt 205, der Hochwasserzählung umfaßt ein Einstellen eines Wertes in dem Hochwasserzählungs- Feld der Datenstruktur des Kopfzeigers gleich der gegenwärtigen Größe der verketteten Liste, da die gegenwärtige Größe der verketteten Liste so groß ist, wie die verkettete Liste zu diesem Zeitpunkt jemals war. Das Erfassungsverfahren 120 kehrt dann bei 207 zu dem Speicherleckerfassungsverfahren 100 zurück.
  • Fig. 4 ist ein Flußdiagramm eines Verfahrens zum Prüfen auf Speicherlecks verketteter Listen in laufenden Programmen hin, das allgemein durch das Bezugszeichen 135 bezeichnet ist, das durch den Algorithmus der Wachstumsprüfung der verketteten Liste ausgeführt ist. Das Prüfverfahren 135 umfaßt einen Schritt 210 eines Bestimmens, ob eine neue Größe der verketteten Liste größer als die Hochwasserzählung ist, einen Schritt 214 eines Definierens der Hochwasserzählung als die neue Größe der verketteten Liste, einen Schritt 216 eines Bestimmens, ob eine langlebige Zeitgrenze verstrichen ist, einen Schritt 240 eines Berichtens eines Wachstums der verketteten Liste und einer Möglichkeit eines Speicherlecks und einen Schritt 250 eines Zurückkehrens zu dem Speicherleckerfassungsverfahren bei 100.
  • Der Schritt 210 des Bestimmens, ob eine neue Größe der verketteten Liste größer als die Hochwasserzählung der verketteten Liste ist, umfaßt ein Lesen des Gegenwärtige-Größe- Feldes der Datenstruktur des Kopfzeigers, das nun die neue Größe der verketteten Liste anzeigt, nachdem die verkettete Liste größenmäßig zugenommen hat, und ein Vergleichen der gegenwärtigen Größe mit der Hochwasserzählung der verketteten Liste. Wenn die neue gegenwärtige Größe der verketteten Liste nicht größer als die gegenwärtige Hochwasserzählung der verketteten Liste ist, kehrt das Prüfverfahren 135 bei Schritt 250 zurück zu dem Fehlerleckerfassungsverfahren 100. Wenn die Belastungsprüfung nicht abgeschlossen ist, wartet das Speicherleckerfassungsverfahren 100, bis die verkettete Liste größenmäßig wieder zunimmt (Fig. 2), wobei zu diesem Zeitpunkt der Vergleich zwischen der neuen Größe und der gegenwärtigen Hochwasserzählung wieder durchgeführt wird. Eine derartige Situation würde z. B. entstehen, wenn die verkettete Liste mehrere Elemente verliert, seit sie die gegenwärtige Hochwasserzählung erreicht hat, und dann einige Elemente gewinnt, wodurch der Algorithmus zur Wachstumsprüfung der verketteten Liste ausgelöst wird. Wenn die Anzahl von Elementen, die durch die verkettete Liste gewonnen werden, jedoch die Anzahl verlorener Elemente nicht überschreitet, erreicht die Gesamtanzahl von Elementen, die nun in der verketteten Liste sind, nicht die gegenwärtige Hochwasserzählung.
  • Wenn jedoch die neue Größe der verketteten Liste größer als die Hochwasserzählung ist, was anzeigt, daß die verkettete Liste größenmäßig über den größten Punkt hinaus zugenommen hat, an dem sich die verkettete Liste bis zu diesem Punkt jemals befand, wird die Hochwasserzählung bei Schritt 216 als die neue Größe der verketteten Liste neu definiert, wobei das Prüfverfahren 135 die verkettete Liste als eine Möglichkeit zum Speicherleck markiert. In dem Zusammenhang der vorherigen Beispiele würde dies auftreten, wenn die verkettete Liste mehr Elemente dazugewinnen als verlieren würde. Wie bereits erläutert wurde, sind jedoch nur langlebige verkettete Listen von Belang. Deshalb bestimmt das Prüfverfahren 135 als nächstes bei einem Schritt 216, ob eine langlebige Zeitgrenze verstrichen ist.
  • Der Schritt 216 des Bestimmens, ob die langlebige Zeitgrenze verstrichen ist, umfaßt ein Vergleichen einer gegenwärtigen Zeit mit der Erzeugungszeit und ein Bestimmen, ob der Unterschied dieser beiden Zeiten größer oder gleich der langlebigen Zeitgrenze ist. Der Programmentwickler setzt die langlebige Zeitgrenze, die eine Schwelle dafür ist, wie lang eine verkettete Liste nach ihrer Erzeugung existieren muß, um als langlebig betrachtet zu werden. Der Programmentwickler kann z. B. entscheiden, daß jede verkettete Liste, die zwei Stunden oder länger, nachdem sie erzeugt wurde, noch existiert, eine langlebige verkettete Liste ist. Sobald die Erzeugung einer verketteten Liste bei Schritt 120 (Fig. 2) erfaßt ist, wird der Systemtakt jedesmal abgefragt, wenn die verkettete Liste größenmäßig über die dann existierende Hochwasserzählung hinaus ansteigt, um zu bestimmen, ob die Dauer der langlebigen Zeitgrenze seit dem Zeitpunkt, zu dem die verkettete Liste erzeugt wurde, verstrichen ist. Wenn die langlebige Zeitgrenze nicht verstrichen ist, kehrt das Prüfverfahren 135 bei Schritt 250 zurück zu dem Speicherleckerfassungsverfahren 100. Das Speicherleckerfassungsverfahren 100 wartet dann, bis die verkettete Liste wieder größenmäßig zunimmt, wenn die Belastungsprüfung nicht abgeschlossen ist.
  • Wenn die langlebige Zeitgrenze verstrichen ist, ist die verkettete Liste langlebig und sollte an diesem Punkt stabil sein. Jedes Wachstum der verketteten Liste, nachdem die langlebige Zeitgrenze verstrichen ist, ist eine Anzeige eines möglichen Speicherlecks. Deshalb wird, da die neue Größe der verketteten Liste größer als die Hochwasserzählung ist, das Wachstum bei Schritt 240 berichtet, um die Möglichkeit, daß die betrachtete verkettete Liste ein Speicherleck aufweist, anzuzeigen. Der Schritt 240 des Berichtens wird unten Bezug nehmend auf Fig. 5 detaillierter beschrieben. Das Prüfverfahren 135 kehrt dann bei Schritt 250 zu dem Speicherleckerfassungsverfahren 100 zurück, wobei das Verfahren 100 dann bei Schritt 140 bestimmt, ob die Dauer der Belastungsprüfung des Programms 30, das gerade entwickelt wird, verstrichen ist, wie bereits erklärt wurde. Wenn die Dauer der Belastungsprüfung nicht verstrichen ist, fährt das Speicherleckerfassungsverfahren 100 fort, um alle Größenanstiege in der verketteten Liste zu verfolgen, bis die Belastungsprüfung des Programms 30 abgeschlossen ist. Verkettete Listen, die eine frühere maximale Größe erreicht haben, werden fortdauernd auf ein Wachstum über ihre vorherigen maximalen Größen hinaus hin überwacht, wobei neu erzeugte verkettete Listen ebenfalls überwacht werden, wie bereits erläutert wurde, da das Prüfverfahren 135 gleichzeitig mehrere verkettete Listen überwachen kann.
  • Fig. 5 ist ein Flußdiagramm eines Verfahrens zum Berichten eines möglichen Speicherlecks in einer stabilen verketteten Liste. Das Berichtverfahren bei Schritt 240 umfaßt bei Schritt 400 ein Drucken einer Berichtsnachricht an ein Nachrichtenprotokoll, bei Schritt 410 ein Drucken einer Stapelspur an das Nachrichtenprotokoll und dann bei Schritt 420 ein Zurückkehren zu dem Prüfverfahren 135.
  • Das Drucken, bei Schritt 400, der Berichtsnachricht an das Nachrichtenprotokoll umfaßt ein Anzeigen der Berichtsnachricht an dem Computersystem 100 durch die Ausgabevorrichtung 24 oder die Anzeigevorrichtung 26. Das Nachrichtenprotokoll nimmt vorzugsweise die Form eines Papierberichts an, den ein Programmentwickler nach der Fertigstellung der Belastungsprüfung des Programms 30, das gerade entwickelt wird, durchschauen kann. Bei einem alternativen Ausführungsbeispiel kann das Nachrichtenprotokoll eine Textdatei sein, die der Programmentwickler wiedergewinnen und betrachten kann. Der Bericht umfaßt vorzugsweise Informationen hinsichtlich des Namens der verdächtigen verketteten Liste, der gegenwärtigen Hochwasserzählung der verdächtigen verketteten Liste, der Zeit, wie lange die verdächtige verkettete Liste existiert hat, und des Zeitpunkts, zu dem die verdächtige verkettete Liste zuletzt größenmäßig angestiegen ist. Der Programmentwickler verwendet diese Informationen, um zu bestimmen, ob es ein Speicherleck in einer der verketteten Listen gibt, die in dem Programm 30 existieren. Das Drucken, bei Schritt 410, der Stapelspur an das Nachrichtenprotokoll umfaßt ähnlich ein Anzeigen der Stapelspur des Programmierungscodes, der die Größe der verdächtigen verketteten Liste erhöht hat, an dem Computersystem 10 durch die Ausgabevorrichtung 24 oder die Anzeigevorrichtung 26. Der Programmentwickler kann dann die Stapelspur durchgehen und den geeigneten Code prüfen, um den Programmierfehler zu finden, der das Speicherleck in der verdächtigen verketteten Liste bewirkt. Der Programmentwickler kann dann den Programmcode des Programms 30 bearbeiten, um den Fehler zu beheben.

Claims (14)

1. Verfahren mit folgenden Schritten:
Speichern (214) einer gegenwärtigen Größe einer verketteten Liste während eines ersten vorbestimmten Zeitraums als eine neue maximale Größe der verketteten Liste, wenn ein neues Element zu der verketteten Liste hinzugefügt wird, wobei das neue Element ein Element ist, das bewirkt, daß die gegenwärtige Größe der verketteten Liste eine frühere maximale Größe der verketteten Liste überschreitet;
Bestimmen (216), ob der erste vorbestimmte Zeitraum abgelaufen ist, wenn die gegenwärtige Größe der verketteten Liste die frühere maximale Größe der verketteten Liste überschreitet; und
Bestimmen (210), ob die neue maximale Größe der verketteten Liste die frühere maximale Größe der verketteten Liste während eines zweiten vorbestimmten Zeitraums überschreitet, wobei der zweite vorbestimmte Zeitraum sich über das Ende des ersten vorbestimmten Zeitraums hinaus erstreckt.
2. Verfahren gemäß Anspruch 1, das ferner einen Schritt des Erzeugens (240) eines Berichts aufweist, wenn die neue maximale Größe der verketteten Liste die frühere maximale Größe der verketteten Liste während des zweiten vorbestimmten Zeitraums überschreitet.
3. Verfahren gemäß Anspruch 2, bei dem der Bericht einen Namen der verketteten Liste, eine Dauer der verketteten Liste, eine Zeit seit dem Zeitpunkt, zu dem die verkettete Liste zuletzt größenmäßig angestiegen ist, oder eine gegenwärtige Größe der verketteten Liste umfaßt.
4. Verfahren gemäß Anspruch 2 oder 3, bei dem der Bericht eine Stapelspur umfaßt, die einen Programmcode eines Prozeduraufrufs in einem laufenden Programm anzeigt, der die Größe der verketteten Liste erhöht hat.
5. Verfahren gemäß einem der Ansprüche 1 bis 4, das ferner folgende Schritte aufweist:
Speichern (200) einer Erzeugungszeit der vetketteten Liste, wenn die verkettete Liste erzeugt wird; und
Beibehalten (205, 214) der gegenwärtigen Größe der verketteten Liste.
6. Computerlesbares Medium, das Module zum Steuern eines Prozessors umfaßt, wobei die Module folgende Merkmale aufweisen:
ein Modul (214) zum Speichern einer gegenwärtigen Größe einer verketteten Liste während eines ersten vorbestimmten Zeitraums als eine neue maximale Größe der verketteten Liste, wenn ein neues Element zu der verketteten Liste hinzugefügt wird, wobei das neue Element ein Element ist, das bewirkt, daß die gegenwärtige Größe der verketteten Liste eine frühere maximale Größe der verketteten Liste überschreitet;
ein Modul (216) zum Bestimmen, ob ein erster vorbestimmter Zeitraum verstrichen ist, wenn die gegenwärtige Größe der verketteten Liste die frühere maximale Größe der verketteten Liste überschreitet; und
ein Modul (210) zum Bestimmen, ob eine neue maximale Größe der verketteten Liste, nachdem der erste vorbestimmte Zeitraum verstrichen ist, die frühere maximale Größe der verketteten Liste während eines zweiten vorbestimmten Zeitraums überschreitet, wobei der zweite vorbestimmte Zeitraum sich über das Ende des ersten vorbestimmten Zeitraums hinaus erstreckt.
7. Computerlesbares Medium gemäß Anspruch 6, das ferner ein Modul (240) zum Erzeugen eines Berichts aufweist, wenn die neue maximale Größe der verketteten Liste die frühere maximale Größe der verketteten Liste während des zweiten vorbestimmten Zeitraums überschreitet.
8. Computerlesbares Medium gemäß Anspruch 7, bei dem der Bericht einen Namen der verketteten Liste, eine Dauer der verketteten Liste, eine Zeit seit dem Zeitpunkt, zu dem die verkettete Liste zuletzt größenmäßig anstieg, oder eine gegenwärtige Größe der verketteten Liste umfaßt.
9. Computerlesbares Medium gemäß Anspruch 7 oder 8, bei dem der Bericht eine Stapelspur umfaßt, die einen Programmcode eines Prozeduraufrufs in dem laufenden Programm anzeigt, der die Größe der verketteten Liste erhöht hat.
10. Computerlesbares Medium gemäß einem der Ansprüche 6 bis 9, das ferner folgende Merkmale aufweist:
ein Modul (200) zum Speichern einer Erzeugungszeit der verketteten Liste, wenn die verkettete Liste erzeugt wird; und
ein Modul (205, 214) zum Beibehalten der gegenwärtigen Größe der verketteten Liste.
11. System (10), das einen Prozessor (34), eine Ausgabevorrichtung (24) und einen Speicher (20, 28) zum Speichern eines Programmcodes eines laufenden Programms (30) umfaßt, und das Module (32) zum Steuern des Prozessors umfaßt, wobei die Module folgende Merkmale aufweisen:
ein Modul (214) zum Speichern einer gegenwärtigen Größe einer verketteten Liste während eines ersten vorbestimmten Zeitraums als eine neue maximale Größe der verketteten Liste, jedesmal, wenn ein neues Element zu der verketteten Liste hinzugefügt wird, wobei das neue Element ein Element ist, das bewirkt, daß die gegenwärtige Größe der verketteten Liste eine frühere maximale Größe der verketteten Liste überschreitet;
ein Modul (216) zum Bestimmen, ob ein erster vorbestimmter Zeitraum verstrichen ist, wenn die gegenwärtige Größe der verketteten Liste die frühere maximale Größe der verketteten Liste überschreitet; und
ein Modul (210) zum Bestimmen, ob eine neue maximale Größe der verketteten Liste die frühere maximale Größe der verketteten Liste während eines zweiten vorbestimmten Zeitraums überschreitet, wobei der zweite vorbestimmte Zeitraum sich über das Ende des ersten vorbestimmten Zeitraums hinaus erstreckt,
wobei der Prozessor das laufende Programm ausführt und die Module ausführt, und
wobei die Ausgabevorrichtung einen Bericht anzeigt, wenn die gegenwärtige Größe der verketteten Liste die frühere maximale Größe der verketteten Liste überschreitet.
12. System gemäß Anspruch 11, bei dem der Bericht einen Namen der verketteten Liste, eine Dauer der verketteten Liste, eine Zeit seit dem Zeitpunkt, zu dem die verkettete Liste zuletzt größenmäßig anstieg, oder eine gegenwärtige Größe der verketteten Liste umfaßt.
13. System gemäß Anspruch 11 oder 12, bei dem der Bericht eine Stapelspur umfaßt, die einen Programmcode eines Prozeduraufrufs in dem laufenden Programm anzeigt, der die Größe der verketteten Liste erhöht hat.
14. System gemäß einem der Ansprüche 11 bis 13, das ferner folgende Merkmale aufweist:
ein Modul (200) zum Speichern einer Erzeugungszeit der verketteten Liste, wenn die verkettete Liste erzeugt wird; und
ein Modul (205, 214) zum Beibehalten der gegenwärtigen Größe der verketteten Liste.
DE10240883A 2001-09-17 2002-09-04 Verfahren zum Erfassen eines unbegrenzten Wachstums verketteter Listen in einer laufenden Anwendung Withdrawn DE10240883A1 (de)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US09/953,276 US6892378B2 (en) 2001-09-17 2001-09-17 Method to detect unbounded growth of linked lists in a running application

Publications (1)

Publication Number Publication Date
DE10240883A1 true DE10240883A1 (de) 2003-04-24

Family

ID=25493772

Family Applications (1)

Application Number Title Priority Date Filing Date
DE10240883A Withdrawn DE10240883A1 (de) 2001-09-17 2002-09-04 Verfahren zum Erfassen eines unbegrenzten Wachstums verketteter Listen in einer laufenden Anwendung

Country Status (3)

Country Link
US (1) US6892378B2 (de)
DE (1) DE10240883A1 (de)
GB (1) GB2383857B (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107423220A (zh) * 2017-08-04 2017-12-01 青岛海信宽带多媒体技术有限公司 内存泄露的检测方法及装置、电子设备

Families Citing this family (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030225872A1 (en) * 2002-05-29 2003-12-04 International Business Machines Corporation Consolidated management of remot and local application logs
US7234080B2 (en) * 2002-10-18 2007-06-19 Computer Associates Think, Inc. Locating potential sources of memory leaks
US7089460B2 (en) * 2003-02-28 2006-08-08 Microsoft Corporation System and method for memory leak detection
US7577943B2 (en) * 2003-10-24 2009-08-18 Microsoft Corporation Statistical memory leak detection
US8640116B2 (en) * 2004-02-26 2014-01-28 Broadcom Corporation Loader module, and method for loading program code into a memory
US7487321B2 (en) * 2004-04-19 2009-02-03 Cisco Technology, Inc. Method and system for memory leak detection
US7870170B2 (en) * 2005-05-03 2011-01-11 International Business Machines Corporation Method and apparatus for determining leaks in a Java heap
US7496795B2 (en) * 2005-06-02 2009-02-24 International Business Machines Corporation Method, system, and computer program product for light weight memory leak detection
US7774761B2 (en) * 2005-12-27 2010-08-10 International Business Machines Corporation Use of memory watch points and a debugger to improve analysis of runtime memory access errors
US7500079B2 (en) * 2006-07-31 2009-03-03 Microsoft Corporation Detection of memory leaks
US8037477B2 (en) * 2007-01-23 2011-10-11 Hewlett-Packard Development Company, L.P. Efficient detection of sources of increasing memory consumption
US8601469B2 (en) * 2007-03-30 2013-12-03 Sap Ag Method and system for customizing allocation statistics
US8522209B2 (en) * 2007-03-30 2013-08-27 Sap Ag Method and system for integrating profiling and debugging
US8356286B2 (en) * 2007-03-30 2013-01-15 Sap Ag Method and system for providing on-demand profiling infrastructure for profiling at virtual machines
US8336033B2 (en) * 2007-03-30 2012-12-18 Sap Ag Method and system for generating a hierarchical tree representing stack traces
US8667471B2 (en) * 2007-03-30 2014-03-04 Sap Ag Method and system for customizing profiling sessions
US7895483B2 (en) * 2007-05-25 2011-02-22 International Business Machines Corporation Software memory leak analysis using memory isolation
CN100498740C (zh) * 2007-09-11 2009-06-10 腾讯科技(深圳)有限公司 一种数据缓存处理方法、系统及数据缓存装置
US8312457B2 (en) * 2009-12-14 2012-11-13 Microsoft Corporation Maintaining a count for lock-free linked list structures
CN102495763B (zh) * 2011-11-18 2013-05-15 成都易我科技开发有限责任公司 计算机程序内存动态配置方法
US9947044B2 (en) * 2014-01-06 2018-04-17 Bank Of America Corporation Improper financial activity detection tool
US9811484B1 (en) * 2014-06-30 2017-11-07 Altera Corporation Methods and apparatus for rapid interrupt lookups
EP3221987A1 (de) * 2014-11-21 2017-09-27 Telefonaktiebolaget LM Ericsson (publ) Signalverarbeitungsvorrichtung und -verfahren
US20170017567A1 (en) 2015-07-15 2017-01-19 Innovium, Inc. System And Method For Implementing Distributed-Linked Lists For Network Devices
US20170017420A1 (en) 2015-07-15 2017-01-19 Innovium, Inc. System And Method For Enabling High Read Rates To Data Element Lists
US20170017419A1 (en) 2015-07-15 2017-01-19 Innovium, Inc. System And Method For Enabling High Read Rates To Data Element Lists
US20170017414A1 (en) * 2015-07-15 2017-01-19 Innovium, Inc. System And Method For Implementing Hierarchical Distributed-Linked Lists For Network Devices
US10296612B2 (en) 2015-09-29 2019-05-21 At&T Mobility Ii Llc Sorting system
US10416959B2 (en) 2015-10-27 2019-09-17 At&T Mobility Ii Llc Analog sorter
US10261832B2 (en) * 2015-12-02 2019-04-16 At&T Mobility Ii Llc Sorting apparatus
US10496370B2 (en) 2015-12-02 2019-12-03 At&T Intellectual Property I, L.P. Adaptive alphanumeric sorting apparatus
CN110727585B (zh) * 2019-09-11 2023-07-21 锐捷网络股份有限公司 内存泄漏检测方法、装置、电子设备及可读存储介质

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5193180A (en) * 1991-06-21 1993-03-09 Pure Software Inc. System for modifying relocatable object code files to monitor accesses to dynamically allocated memory
US5784699A (en) * 1996-05-24 1998-07-21 Oracle Corporation Dynamic memory allocation in a computer using a bit map index
US6269477B1 (en) * 1997-09-16 2001-07-31 Microsoft Corporation Method and system for improving the layout of a program image using clustering
US6654773B2 (en) * 2001-02-27 2003-11-25 Tajea Corporation Method of deterministic garbage collection

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107423220A (zh) * 2017-08-04 2017-12-01 青岛海信宽带多媒体技术有限公司 内存泄露的检测方法及装置、电子设备

Also Published As

Publication number Publication date
US20030061597A1 (en) 2003-03-27
GB2383857A (en) 2003-07-09
GB0220476D0 (en) 2002-10-09
GB2383857B (en) 2005-06-08
US6892378B2 (en) 2005-05-10

Similar Documents

Publication Publication Date Title
DE10240883A1 (de) Verfahren zum Erfassen eines unbegrenzten Wachstums verketteter Listen in einer laufenden Anwendung
DE69919632T2 (de) Fehlertoleranz durch N-modulare Softwareredundanz unter Verwendung von indirekter Instrumentierung
DE4108590C2 (de) Verfahren zum Benchmark-Testen der Arbeitsgeschwindigkeit eines Computersystem
DE10050684B4 (de) Verfahren und System zur periodischen Ablaufverfolgung für Aufrufsequenzen zwischen Routinen
DE69210399T2 (de) Rechnerueberwachungsverfahren und system
DE4118454C2 (de) System zum automatischen Testen von Anwendersoftware
DE69112694T2 (de) Verfahren zum Betrieb eines Datenverarbeitungssystems zur Ausführung von Datenbanktransaktionen.
DE60214862T2 (de) Methode für die verbesserte verwaltung von einer ereignisdatenbasis und system für ereignismeldung in einem netzwerk
DE69913375T2 (de) Anzeige eines fehlers in einem transaktionsverarbeitungssystem
DE202012013432U1 (de) Speichern von Daten auf Speicherknoten
DE60314742T2 (de) System und verfahren zur überwachung eines computers
EP2056201A2 (de) Verfahren, Rechnersystem und Computerprogrammprodukt
DE10127170A1 (de) Fehlersuchverfahren und Fehlersuchvorrichtung
DE102006041444B4 (de) Schaltungsanordnung und Verfahren zum Erfassen einer Ausführungszeit eines Befehls in einem Rechnersystem
DE10309246A1 (de) Verfahren für das Event Management
DE202017106569U1 (de) Analyse grossangelegter Datenverarbeitungsaufträge
DE202016008043U1 (de) Vorrichtung zum Erzeugen, Erfassen, Speichern und Laden von Debugging-Informationen für gescheiterte Test-Skripts
DE10115722A1 (de) Effiziente Echtzeitverwaltung von Speicherbetriebsmitteln
EP1067460A1 (de) Datenträger mit wiederherstellbarem Basisdatengrundzustand und Verfahren zu dessen Herstellung
DE112011100168T5 (de) Erfassen von Diagnosedaten in einer Datenverarbeitungsumgebung
DE10213009A1 (de) Verfahren zum elektronischen Testen von Speichermodulen
WO2000043885A1 (de) Verfahren zum tracen von daten
DE10392916T5 (de) Selbsttestsystem
DE102019135079A1 (de) Installation von firmware-bundles abbrechen
DE102014210192A1 (de) Die Erfindung betrifft ein Verfahren zur Überprüfung von Invarianten in parallelen Programmen

Legal Events

Date Code Title Description
OP8 Request for examination as to paragraph 44 patent law
8125 Change of the main classification

Ipc: G06F 1136

8127 New person/name/address of the applicant

Owner name: HEWLETT-PACKARD DEVELOPMENT CO., L.P., HOUSTON, TE

8130 Withdrawal