-
Technisches
Gebiet
-
Die vorliegende Erfindung bezieht
sich allgemein auf Computersysteme und insbesondere auf eine plattformunabhängige Speicherabbild-Analysearchitektur
zur Fehlersuche bei einem Computerprogramm.
-
Hintergrund
der Erfindung
-
Bei der Fehlersuche (Debuggen) eines
Computerprogramms werden allgemein Daten in einer Speicherabbilddatei
manipuliert, die einen Schnappschuss des vom Computerprogramm verwendeten Speichers
enthält.
Die Speicherabbilddatei kann entweder während der Ausführung des
Computerprogramms oder zu einer Zeit eines auftretenden Fehlers
des Computerprogramms erzeugt werden. Eine während der Ausführung erzeugte
Speicherabbilddatei ist als Laufzeitabzug (run time dump) bekannt, während eine
zur Zeit eines auftretendes Fehlers erzeugte Speicherabbilddatei
als Absturzprotokoll ("crash
dump" oder "post-mortem dump") bezeichnet wird.
-
Zur richtigen Analyse einer Speicherabbilddatei
müssen
die Datentypen der in der Speicherabbilddatei enthaltenen Daten
berücksichtigt
werden. Definitionen der Datentypen sind im Quellcode des Computerprogramms
enthalten. Wenn eine Partei die Speicherabbilddatei manuell decodieren
möchte, untersucht
die Partei den Quellcode auf der Suche nach Datentypdefinitionen
innerhalb des Quellcodes. Dann wendet die Partei die festgestellten
Datentypdefinitionen zur Interpretation der Daten in der Speicherabbilddatei
an. Die Partei kann stattdessen auch allgemeine automatisierte Anwendungs-Fehlersuchprogramme
verwenden, die bei der Analyse der Daten in der Speicherabbilddatei
helfen. Das Fehlersuchprogramm liest die Datentypdefinitionen aus Fehlersuchtabellen,
die von einem Compiler aufgebaut wurden, als das Computerprogramm
kompiliert wurde.
-
Parteien können auch eigens erstellte
Werkzeuge zur Unterstützung
bei der Untersuchung der Speicherabbilddatei verwenden. Diese eigens
erstellten Werkzeuge (custom tools) werden typischerweise nach Kundenwunsch
erstellt, um eine bestimmte Art einer Speicherabbilddatei zu untersuchen.
Zum Beispiel können
solche automatisierten eigens erstellten Werkzeuge kundenspezifisch
so ausgelegt sein, dass sie Speicherabbilddateien für eine bestimmte
Instanz eines Betriebssystems untersuchen (z.B. eine bestimmte Version
eines Betriebssystems, die auf einer bestimmten Hardwareplattform
läuft).
-
Eine Schwierigkeit bei herkömmlichen
Tools ist die statische Art der Datentypdefinitionen. Datentypdefinitionen
sind oft dahingehend statisch, dass sie an eine bestimmte Plattform,
eine bestimmte Betriebssystemversion, einen Patch oder eine Patchversion
gebunden sind. Zum Beispiel kann der Datentyp integer ("int") für eine erste
Hardwareplattform als ein vorzeichenbehafteter 16-Bit-Wert, bei
seiner Definition für
eine zweite Hardwareplattform als ein vorzeichenbehafteter 32-Bit-Datentyp
und bei seiner Definition für
eine dritte Hardwareplattform als ein vorzeichenbehafteter 64-Bit-Datentyp
bezeichnet sein. Jede Datentyprepräsentierung ist statisch in
die Programmquelldatei eingeschrieben und statisch in die Fehlersuchtabellen
codiert, die vom Compiler erzeugt werden, wenn die Programmquelldatei
kompiliert wird.
-
Automatisierte Fehlersuchwerkzeuge
sind so aufgebaut, dass sie Speicherabbilddateien für eine bestimmte
Hardwareplattform und eine bestimmte Version eines Betriebssystems
mit einem bestimmten Satz von Patches verstehen und interpretieren.
Folglich können
automatisierte Fehlersuchwerkzeuge nicht auf einer Vielzahl von
Hardwareplattformen mit einer Vielzahl von Versionen des Betriebssystems
oder mit vielfachen Instanzen des Betriebssystems, das unterschiedliche
Patches enthält,
verwendet werden. Daher müssen
eigene automatisierte Fehlersuchwerkzeuge für jede Kombination einer Hardwareplattform,
einer Betriebssystemsversion und eines Patches vorgesehen werden.
-
Es gibt Werkzeuge zum Kompilieren
eines Satzes von Kopfdateien in ein spezielles Format, das eine
spezielle eine Struktur beschreibende Information enthält, so dass
ein Satz von Formatierungsfunktionen den Speicher für ein Fehlersuchprogramm
anzeigen kann. Diese Werkzeuge bieten eine Möglichkeit zur Formatierung
von Speicherstrukturen über unterschiedliche
Fehlersuchumgebungen hinweg. Solche Werkzeuge sind jedoch ineffizient,
weil sie eine große
Anzahl zu handhabender Dateien erzeugen, und diese Dateien für die Umgebung,
in der sie sich befinden, spezifisch sind. Dadurch wird die Reichweite
der zur potentiellen Verwendung kommenden Typen von Speicherstrukturen
eingeschränkt.
-
Ein Beispiel eines bekannten Verfahrens zum
Erzeugen einer Datei, so dass ein Speicher für einen Abzugsformatierer oder
ein Fehlersuchprogramm in einem strukturierten Format angezeigt
werden kann, ist in "Structure
Formatting for Dump Formatters and Debuggers" ("Strukturierte
Formatierung für
Abzugsformatierer und Fehlersuchprogramme"), IBM Technical Disclosure Bulletin,
Band 38, Nr. 4, April 1995, Seiten 481-483 beschrieben.
-
Zusammenfassung
der Erfindung
-
Die vorliegende Erfindung sieht ein
plattformunabhängiges
Verfahren zum Analysieren eines Speicherabbilds nach Anspruch 1
und ein Computersystem nach Anspruch 12 vor. Weitere bevorzugte Aspekte
der Erfindung sind gemäß der davon
abhängenden
Ansprüche
vorgesehen.
-
Die vorliegende Erfindung befasst
sich mit den oben beschriebenen Einschränkungen herkömmlicher
Speicherabbilddatei-Analysewerkzeuge. Die vorliegende Erfindung
sieht eine Analysearchitektur vor, die plattformunabhängig ist
(d.h. nicht statisch von einer zugrunde liegenden Plattform abhängig), nicht
an eine bestimmte Version eines Programms gebunden und nicht abhängig von
der Anwesenheit oder Abwesenheit von Patches. Diese Analysearchitektur
stellt die Datentypdefinitionen dynamisch fest, um die Hardwarearchitektur
zu berücksichtigen,
auf der das Programm läuft,
um die Version des laufenden Programms zu berücksichtigen, und um die Anwesenheit
oder Abwesenheit von Patches zu berücksichtigen. Die Datentypdefinitionen
können zu
der Zeit, in der eine Anforderung zur Betrachtung einer vorgegebenen
Datenstruktur oder eines Objekts innerhalb der Speicherabbilddatei
getätigt
wird, vollständig
aufgelöst
werden. Die vorliegende Erfindung ermöglicht auch ein symbolisches
Zugreifen auf Daten, um die Bequemlichkeit zu erhöhen, mit
der auf die Daten in der Speicherabbilddatei zugegriffen werden
kann.
-
Nach einem Aspekt der vorliegenden
Erfindung enthält
eine Rechnerumgebung Werkzeuge zum Zugreifen auf Daten in Speicherabbildern.
Eine erste Programmquelle definiert einen Datentyp, der eine erste
Menge von Eigenschaften hat (z.B. Größe, Ausrichtung, usw.). Ein
erstes Speicherabbild wird für die
erste Programmquelle erzeugt. Eine zweite Programmquelle definiert
ebenfalls den Datentyp, definiert jedoch den Datentyp so, dass er
eine zweite Menge von Eigenschaften hat, die sich von der ersten
Menge von Eigenschaften unterscheidet. Ein zweites Speicherabbild
wird für
die zweite Programmquelle vorgesehen. Ein Analysewerkzeug wird zum
dynamischen Feststellen der ersten Menge der Eigenschaften des Datentyps
verwendet. Das Analysewerkzeug verwendet das Wissen über die
erste Menge von Eigenschaften und greift auf Daten des Datentyps
der ersten Programmquelle zu. Das selbe Analysewerkzeug stellt dynamisch
die zweite Menge von Eigenschaften des Datentyps fest und verwendet das
Wissen über
die zweite Menge von Eigenschaften zum Zugreifen auf Daten in der
zweiten Programmquelle. Die erste Programmquelle und die zweite
Programmquelle können
Computerprogramme sein, wie zum Beispiel Betriebssysteme oder sogar
unterschiedliche Versionen eines gemeinsamen Betriebssystems. Die
erste Programmquelle und die zweite Programmquelle können sich
dadurch unterscheiden, ob sie einen bestimmten Patch enthalten oder
nicht. Auf diese Weise ist das Analysewerkzeug nicht statisch an
eine einzige Programmquelle gebunden, sondern kann vielmehr mit
vielfachen Programmquellen eingesetzt werden.
-
Eine Computerprogramm kann verarbeitet werden,
wie zum Beispiel indem das Computerprogramm durch einen Compiler
laufen gelassen wird, um computersystemunabhängige Attribute eines innerhalb
des Computerprogramms definierten ausgewählten Datentyps zu identifizieren.
Diese Attribute können
Attribute enthalten, die nicht an die Computerplattform gebunden
sind, auf welcher das Programm läuft.
Die computersystemunabhängigen
Attribute werden in einem Template gespeichert. Das Template wird
dann nachfolgend beim Zugreifen auf Daten im Speicherabbild des
ausgewählten
Datentyps verwendet. Das Template kapselt die computersystemunabhängigen Attribute
ein. Das Template kann zum Überwinden
der Einschränkungen
statischer Datentypdefinitionen verwendet werden, indem eine Charakterisierung
des Datentyps vorgesehen wird, die keine Computersystemabhängigkeiten hat.
Dadurch entwickelt das Abbildanalysewerkzeug keinen Fehler oder
stürzt
nicht ab, wenn es auf Daten in einem Format trifft, das vom erwarteten
abweicht.
-
Kurzbeschreibung
der Zeichnungen
-
Eine veranschaulichende Ausführungsform, die
den Prinzipien der vorliegenden Erfindung treu ist, wird unten anhand
der folgenden Zeichnungen beschrieben.
-
1 ist
ein Blockdiagramm eines Computersystems, das zur praktischen Umsetzung
der veranschaulichenden Ausführungsform
geeignet ist.
-
2 ist
ein Fließdiagramm,
das einen Überblick
von Schritten bietet, die in der veranschaulichenden Ausführungsform
zum Analysieren einer Speicherabbilddatei durchgeführt werden.
-
3 ist
ein Fließdiagramm,
das die Schritte veranschaulicht, die zum Binden eines Templates
an ein Datentypobjekt durchgeführt
werden.
-
4 ist
ein logisches Diagramm eines Datentypobjekts.
-
5 ist
eine logische Darstellung eines Elements einer Etikettenliste (tag
list).
-
6 veranschaulicht
die Beziehung zwischen einem Datenobjekt, einer Speicherabbilddatei und
einem Datentypobjekt.
-
7 zeigt
ein Beispiel eines Listenobjekts, das aus Datenobjekten erzeugt
wurde.
-
8 zeigt
ein Beispiel einer Verwendung der Analyseeinrichtung zum Analysieren
von Speicherabbilddateien aus unterschiedlichen Programmquellen.
-
9A zeigt
ein Hauptbetrachtungsfenster zum Zugreifen auf Speicherabbilddateidaten.
-
9B zeigt
ein Beispiel eines Objektfensters.
-
9C zeigt
ein Beispiel eines Listenfensters.
-
Detaillierte Beschreibung
der Erfindung.
-
Das Ausführungsbeispiel sieht eine plattformunabhängige Speicherabbild-Analysearchitektur vor,
die bei der Fehlersuche eines Computerprogramms hilft. Die Speicherabbild-Analysearchitektur ist "plattformunabhängig" dahingehend, dass
die Architektur auf unterschiedlichen Hardwareplattformen mit unterschiedlichen
Computerprogrammversionen verwendet werden kann, die Patches enthalten
können.
Die Speicherabbild-Analysearchitektur geht dynamisch auf die Computerprogrammversion
ein, bei der gerade die Fehlersuche durchgeführt wird, auf die Anwesenheit
oder Abwesenheit von Patchen für das
Computerprogramm und auf die zugrunde liegende Hardwarearchitektur,
auf welcher das Computerprogramm läuft. Die Speicherabbild-Analysearchitektur
ist nicht statisch an eine bestimmte Instanz eines Computerprogramms
gebunden. Die Speicherabbild-Analysearchitektur muss nicht jedes
Mal programmiertechnisch überarbeitet
werden, wenn eine unterschiedliche Hardwarekonfiguration eingesetzt wird
oder jedes Mal, wenn eine neue Version des Programms analysiert
wird.
-
Das Ausführungsbeispiel verwendet Datentypdefinitionstemplates
("Templates"), die bei der Überwindung
der Probleme helfen, die durch statische Datentypdefinitionen geschaffen
werden. Jedes Template ist eine Repräsentierung eines Datentyps, die
direkt aus dem Quellcode eines Computerprogramms genommen wird,
in dem der entsprechende Datentyp definiert ist. Das Template reduziert
die Datentypdefinition auf eine reine, einfache, computersystemunabhängige Form.
Die Templates erfassen Eigenschaften des Datentyps, die für die Speicherabbild-Analysearchitektur
bei der Analyse der Daten hilfreich sein können, ohne dass dabei die Gefahr
besteht, dass eine unerwünschte
Abhängigkeit
von der Architektur entsteht. Die Templates können nicht direkt mit der Speicherabbilddatei
verwendet werden, weil die Speicherabbilddatei Computersystemabhängigkeiten
enthält.
Deshalb trifft das Ausführungsbeispiel
Maßnahmen,
um solche Abhängigkeiten
zu berücksichtigen.
Datentypobjekte werden erzeugt, um sowohl die computersystemunabhängigen als
auch die computersystemabhängigen
Aspekte eines Datentyps zu enthalten. Die computersystemabhängigen Aspekte
(wie zum Beispiel die Größe eines
Datentyps, die entsprechende Ausrichtung eines Datentyps und dergleichen)
werden aus einem Programmbetriebskontext gezogen, der alle Informationen
enthält,
die zur Vervollständigung
der computersystemabhängigen
Teile der Datentypdefinitionen nötig
sind.
-
Wenn ein Benutzer der Speicherabbild-Analysearchitektur
auf Daten eines bestimmten Datentyps in der Speicherabbilddatei
zugreifen möchte, baut
die Speicherabbild-Analysearchitektur ein Datentypobjekt für den bestimmten
Datentyp auf. Das Aufbauen des Datentypobjekts beginnt mit dem Laden
eines Templates für
den bestimmten Datentyp in das Datentypobjekt. Die Analysearchitektur
konstruiert das vollständige
Datentypobjekt durch Analysieren der Bestandteile des Templates
zur vollständigen Charakterisierung
des Datentyps. Anfänglich
stellt die Speicherabbild-Analysearchitektur den Datentyp fest,
den das Template repräsentiert.
Zum Beispiel kann die Speicherabbild-Analysearchitektur feststellen, dass
der Datentyp für
das Template ein Feld, ein Datensatz oder ein Grundelement ist.
Der Datentyp kann eines oder mehrere Etiketten (Tags) (d.h. Attribute
oder Felder) enthalten. Die Etiketten werden in rekursiver Weise
verarbeitet, so dass während
der Analyse des jeweiligen Etiketts das Datendefinitionstemplate
für den
Datentyp des Etiketts aufgerufen und ein Skelettdatentypobjekt für das Etikett
erzeugt wird. Wenn das Datentypdefinitionstemplate für das Etikett
ein aggregierter Datentyp ist, werden Templates für die entsprechenden
untergeordneten Etiketten ebenfalls in die Form von Skelett-Datentypobjekten
gebracht.
-
Es sei zum Beispiel angenommen, dass
ein Etikett einen Datensatz eines Datensatzdatentyps repräsentiert.
Weiter sei angenommen, dass der Datensatzdatentyp ein aggregierter
Datentyp ist (d.h. ein Datentyp ist, der Etiketten zusätzlicher
Datentypen enthält)
mit einem untergeordneten Integeretikett und einem untergeordneten
Bool'schen Etikett.
Die zwei Etiketten im Datensatz werden aufgelöst, um die Auflösung des
Datensatzetiketts höhere
Ebene zu vervollständigen.
Dieser rekursive Auflösungsvorgang
wird fortgesetzt, bis alle Skelett-Datentypobjekte zu Grundelementen
aufgelöst
wurden. Die Grundelemente sind Datentypen, die keine Auflösung benötigen. Ein
Integer-Datentyp
ist ein Beispiel eines Grundelements. Bei Erreichen eines Grundelements im
Auflösungsvorgang
beginnt die Speicherabbild-Analysearchitektur
mit einer Rückverfolgung zum
Konvertieren der Skelett-Datentypobjekte
in echte Datentypobjekte durch Anwendung von Abhängigkeiten vom Programmbetriebskontext,
wie zum Beispiel die Größe der Grundelemente
und die richtige Ausrichtung untergeordneter Datentypen.
-
Die Datentypobjekte werden zur Herstellung einer
Einsicht in die Speicherabbilddatei verwendet, indem jede die Anordnung
und die Bedeutung von Daten in der Speicherabbilddatei für einen
bestimmten Datentyp identifiziert. Die Datentypobjekte werden dazu
verwendet, bei der Erzeugung von Datenobjekten für Daten in der Speicherabbilddatei
beizutragen. Die Daten können
dann symbolisch nach Objektnamen referenziert werden, indem das
Datenobjekt referenziert wird. Die Datenobjekte enthalten eine Referenz
auf ein Datentypobjekt für
den Datentyp der referenzierten Daten und eine Referenz auf eine
Adresse in der Speicherabbilddatei, wo die referenzierten Daten
in der Speicherabbilddatei beginnen.
-
Die Speicherabbild-Analysearchitektur
erleichtert den symbolischen Zugriff auf die Speicherabbilddateidaten.
Zum Beispiel kann eine bestimmte Instanz von Daten in der Speicherdatei
symbolisch dadurch referenziert werden, dass ein Benutzer an den
Daten durchzuführende
Aktionen anfordert. Zum Beispiel kann der Benutzer anfordern, dass
die Daten angezeigt werden, indem er einen Objekttyp in der Anforderung
identifiziert. Die Möglichkeit
zum symbolischen Referenzieren von Daten vereinfacht das Benutzerinteraktionsmodell
mit der Speicherabbild-Analysearchitektur erheblich.
-
Die Speicherabbild-Analysearchitektur
ist sowohl erweiterbar als auch flexibel. Die Speicher-Analysearchitektur
ist dahingehend erweiterbar, dass sie das Hinzufügen neuer Datentypen in einem Computerprogramm
ermöglicht.
Da die Speicherabbild-Analysearchitektur nicht an eine bestimmte
Instanz eines Computerprogramms gebunden ist, können neue Datentypen dem Computerprogramm
hinzugefügt
und durch die Speicherabbild-Analysearchitektur entsprechend gehandhabt
werden. Die Speicherabbild-Analysearchitektur ist dahingehend flexibel,
dass sie sich auf Veränderungen
innerhalb der Datentypdefinitionen, die im Computerprogramm enthalten
sind, einrichten kann.
-
Weitgehend kann die Speicherabbild-Analysearchitektur
so betrachtet werden, als ob die Speicherabbilddatei so behandelt
würde,
als ob die Speicherabbilddatei eine objektorientierte Datenbank
wäre. Die
Speicherabbild-Analysearchitektur
baut eine Datenbank von Templates für Datentypen auf und erzeugt
dann Datenobjekte unter Verwendung der Templates und der in der
Speicherabbilddatei enthaltenen Daten. Das Ergebnis ist wie eine
Datenbank aus Objekten für
die Speicherabbilddateidaten, wobei jeder innerhalb des Computerprogramms
definierter Datentyp durch ein zugeordnetes Objekt beschrieben wird.
-
Zur Klärung der folgenden Erörterung
ist es zweckdienlich, einen Teil der unten verwendeten Terminologie
zu erläutern.
-
In der nachfolgenden Erörterung
werden die Begriffe "Objektklasse", "Objekt" und "Instanz" verwendet. Eine "Objektklasse" bezieht sich auf
eine Gruppe von Objekten mit ähnlichen
Attributen, ähnlichem
Verhalten und gemeinsamer Semantik. Eine Objektklassendefinition
bezieht sich auf eine Definition, welche die Attribute und Methoden
oder Funktionen für
eine bestimmte Gruppe von Objekten definiert. Ein Attribut bezieht
sich auf einen Datenwert, der von Objekten in einer bestimmten Objektklasse angenommen
wird. Die Funktionen oder Methoden sind diejenigen, die auf ein
bestimmtes Objekt innerhalb einer Klasse angewendet werden können. Ein "Objekt" bezieht sich auf
eine bestimmte "Instanz" der Objektklasse.
Zum Beispiel kann ein Objekt "myarray" als Feldobjekttyp
definiert werden. Die Objekttypdefinition identifiziert die Attribute
für den
Feldobjekttyp und identifiziert Methoden, die am Feldobjekttyp durchgeführt werden
können.
-
Ein "Patch" ist ein hinzugefügtes Merkmal oder eine hinzugefügte Funktion,
die in einem getrennten Abschnitt des Codes vorgesehen ist, um ein Computerprogramm "zu verschönern".
-
Ein "Computerprogramm" besteht aus einem Satz von Befehlen,
die auf einer Zentraleinheit (CPU) eines Computersystems ausgeführt werden.
Der Begriff "Computerprogramm" umfasst Anwendungen, benutzergeschriebene
Programme, verkäufergeschriebene
Programme, Betriebssysteme und Zusätze (add-ons) zum Betriebssystem.
-
"Datentyp" bezieht sich auf
eine Definition eines Satzes von Daten, der den möglichen
Bereich von Werten für
den Satz identifiziert und wie die Werte im Speicher gespeichert
werden.
-
"Rechnerressourcen" sind Hardware- oder Softwareressourcen,
die ein Computerprogramm möglicherweise
einsetzt.
-
Ein "Compiler" ist ein Programm, das einen Satz von
Symbolen in einen anderen Satz von Symbolen nach einem Regelsatz
umformt. Der Compiler übersetzt
Quellcode in Objektcode. Allgemein wird der Quellcode in einer Hochsprache
geschrieben, die vom Compiler in ausführbaren Maschinencode oder eine
Variation eines Maschinencodes kompiliert.
-
Ein "Speicherabbild" bezieht sich auf einen Schnappschuss
des Speicherplatzes, der von einem Computerprogramm in Anspruch
genommen wird. Die Speicherabbilddatei kann das Produkt einer Abzugseinrichtung
sein.
-
Ein "Template" bezieht sich auf eine Form oder Struktur,
die zum Enthalten von maschinenunabhängiger Information über Datentypen
verwendet wird, die zum Aufbauen von Datenobjekten verwendet werden,
wie unten noch im Einzelnen beschrieben wird.
-
Ein "Betriebssystem" bezieht sich auf ein Computerprogramm
oder eine Software, die zur Steuerung der Zuweisung und der Verwendung
von Hardwareressourcen auf einem Computersystem verantwortlich ist.
Es wird darauf hingewiesen, dass das Betriebssystem nicht an eine
bestimmte Hardwarearchitektur gebunden sein muss, sondern auch in
einer virtuellen Maschine residieren kann, die die zugrundeliegenden
Hardwarearchitekturabhängigkeiten
wegabstrahiert.
-
1 zeigt
ein Computersystem 10 mit einer Hardwarearchitektur, die
zur Durchführung
der veranschaulichenden Ausführungsform
geeignet ist. Der Fachmann wird erkennen, dass die Konfiguration
des Computersystems, die in 1 gezeigt
ist, nur zur Veranschaulichung dient und die vorliegende Erfindung
nicht einschränkt.
Zum Beispiel kann die vorliegende Erfindung auch mit einem verteilten
Rechnersystem oder mit einem eng gekoppelten Computersystem praktiziert
werden, das mehr als einen Prozessor enthält. Außerdem wird der Fachmann erkennen,
dass die Rechnerumgebung, in der die vorliegende Erfindung praktiziert
wird, von den in 1 gezeigten
abweichende Komponenten haben kann.
-
Das Computersystem 10 enthält eine
Zentraleinheit (CPU) 12 zum Ausführen von Computerprogrammbefehlen.
Die CPU 12 kann aus einer beliebigen Anzahl wohlbekannter
herkömmlicher
Mikroprozessoren bestehen. Das Computersystem 10 kann auch
eine Anzahl von Eingabe/Ausgabe-Geräten aufweisen, wie zum Beispiel
eine Videoanzeige 14, eine Tastatur 16, eine Maus 18 und
einen Drucker 20. Das Computersystem 10 kann ein
Modem 22 zur Kommunikation mit entfernten Rechnerressourcen aufweisen.
Das Modem 22 kann ein herkömmliches Modem sein, das die
Verbindung zu einer herkömmlichen
analogen Telefonleitung herstellt, oder kann alternativ dazu ein
Kabelmodem sein, das die Verbindung zu einer Kabelleitung herstellt,
oder ein drahtloses Modem sein, das Daten drahtlos überträgt. Das Computersystem 10 kann
einen Netzwerkadapter 24 zur Schnittstellenbildung zwischen
dem Computersystem und dem Netzwerk 26 aufweisen.
-
Das Computersystem 10 enthält einen
Speicher 28 zur Speicherung sowohl von Programmen als auch
von Daten. Der Speicher 28 kann sowohl einen Primärspeicher
als auch einen Sekundärspeicher
umfassen. Eine Anzahl unterschiedlicher Speichergeräte kann
zur Implementierung des Speichers 28 eingesetzt werden.
Zum Beispiel kann der Speicher 28 ein RAM, ROM, EPROM,
EEPROM, Flashspeicher, Diskettenlaufwerke, Festplattenlaufwerke, optische
Plattenlaufwerke und dergleichen umfassen. Der Speicher 28 enthält eine
Kopie eines Betriebssystems 30. Für die Zwecke der unten folgenden
Erörterung
wird angenommen, dass das Betriebssystem 30 das Solaris-Betriebssystem
von Sun Microsystems, Inc. ist. Der Fachmann wird erkennen, das
die vorliegende Erfindung auch mit anderen Betriebssystemen umgesetzt
werden kann. Allgemeiner kann die vorliegende Erfindung mit einer
Vielzahl unterschiedlicher Typen von Computerprogrammen umgesetzt
werden, wo die Analyse des Speicherabbilds nützlich ist. Der Speicher 28 braucht
nicht lokal vorzuliegen, sondern kann vielmehr auch entfernt angeordnet
sein, wie der entfernte Speicher 27. Der entfernte Speicher 27 kann
den lokalen Speicher 28 ersetzen oder zur geteilten Speicherverantwortung mit
dem lokalen Speicher zusammenarbeiten.
-
Das Betriebssystem 30 kann
einen oder mehrere Patches aufweisen. Es wird angenommen, dass die
angewendeten Patches innerhalb des Codes, aus dem die Patches bestehen,
oder innerhalb von Kopfdateien identifiziert werden. Außerdem wird angenommen,
dass die Versionsnummer des Betriebssystems 30 im Betriebssystemcode
enthalten ist. Noch weiter wird angenommen, dass das Computersystem 10 zum
Identifizieren der Hardwarearchitektur, die darin vorgesehen ist,
fähig ist.
-
Der Speicher 28 enthält eine
Kopie eines Compilers 32, wie zum Beispiel eines C-Compilers. Der
Fachmann wird erkennen, dass die vorliegende Erfindung nicht auf
eine bestimmte Varietät
eines Compilers für
eine bestimmte Programmier-Hochsprache eingeschränkt ist. Der Compiler 32 wird
modifiziert, damit aus dem Quellcode kein Objektcode erzeugt wird;
stattdessen analysiert oder verarbeitet der Compiler das Computerprogramm
(z.B. das Betriebssystem 30) zum Erzeugen von Datentyp-Definitionstemplates
("Templates"). Wie unten noch
näher erläutert wird,
verarbeitet der Compiler 32 das Vertriebssystem 30 auf
der Suche nach reservierten Wörtern,
die Orte identifizieren, an denen Konstanten, Datenstrukturen, Aufzählungen,
Funktionen, Vereinigungen und andere Datentypdefinitionen syntaktisch
identifiziert sind. Der Fachmann wird erkennen, dass die Templates
nicht von einem Compiler erzeugt zu werden brauchen, sondern vielmehr
auch durch andere Mittel erzeugt werden können. Zum Beispiel können in
manchen Umgebungen Interpretieren anstelle von Compilern verwendet
werden. In solchen Umgebungen kann der Interpretieren zum Erzeugen
der Templates modifiziert werden. Ein JavaTM-Interpretieren
ist ein Beispiel eines solchen Interpretierers. Außerdem können bei
einer Anwendung der vorliegenden Erfindung auf ein Computerprogramm,
das in einer anderen Programmiersprache als C geschrieben ist, andere
reservierte Wörter vom
Compiler gesucht werden.
-
Der Speicher 28 enthält eine
Kopie der Analyseeinrichtung 34. Die Analyseeinrichtung 34 ist
das Werkzeug (in der Form eines Moduls, Programms oder eines Satzes
von Programmen), das es einem Benutzer ermöglicht, auf die in der Speicherabbilddatei 36 enthaltenen
Daten zuzugreifen. Die Analyseeinrichtung 34 enthält eine
grafische Benutzerschnittstelle (GUI), die es einem Benutzer erlaubt,
die Daten in der Speicherabbilddatei 36 anzusehen und an
der Speicherabbilddatei Operationen durchzuführen.
-
Die Speicherabbilddatei 36 enthält einen Schnappschuss
eines vom Computerprogramm verwendeten Speichers, der Datenwerte,
Stapelwerte und dergleichen enthält.
Der Fachmann wird erkennen, dass das Speicherabbild nicht in einer "Datei" an sich gespeichert
zu sein braucht, sondern auch in anderer Weise gespeichert sein
kann. Die vorliegende Erfindung arbeitet daher allgemeiner mit einem
Speicherabbild. In der veranschaulichenden Ausführungsform ist die Speicherabbilddatei 36 das
Produkt einer Abzugseinrichtung 40 oder einer anderen Abbildeinrichtung,
die ein Speicherabbild bei einem Fehler im Computerprogramm erzeugt.
Bei der veranschaulichenden Ausführungsform
kann die Abzugseinrichtung 40 eine beliebige Anzahl bekannter
Abzugseinrichtungen sein, die mit dem Betriebssystem zusammenarbeiten.
Zum Beispiel kann die mit dem Solaris-Betriebssystem vorgesehene Absturzprotokolleinrichtung
(crash dump facility) verwendet werden.
-
Der Speicher 28 enthält Templates 37,
Datentypobjekte 38 und Datenobjekte 42. Wie oben
erwähnt,
enthalten die Templates 37 computersystemunabhängige Information über Datentypen.
Die Datentypobjekte 38 enthalten Information, die vom Computerprogramm,
die den Datentyp definiert hat, über
einen Datentyp extrahiert wurde. Diese Extraktion von Information
wird unten noch im Einzelnen beschrieben. Die Datenobjekte 42 ordnen
die Datentypobjekte 38 Daten für eine bestimmte Instanz an
einer bestimmten Adresse innerhalb der Speicherabbilddatei 36 zu.
-
Der Speicher 28 enthält auch
Strukturen, die zur Lokalisierung von Daten und dergleichen hilfreich sind.
Dateilisten (Dictionaries) 43 werden von der Analyseeinrichtung 34 zum
Korrelieren von Datentypen mit Templates und mit Quellcode vorgesehen. Die
Erzeugung der Dateilisten wird unten noch näher beschrieben. Eine Symboltabelle 45 wird
durch die Abzugseinrichtung 40 erzeugt und wird zum Übersetzen
von Symbolen in Adressen verwendet. Zum Beispiel ist Information über Symbole,
die den Namen der Datenstrukturen repräsentieren, in der Symboltabelle 45 enthalten.
Die Symboltabelle 45 identifiziert die Startadressen bestimmter
Datenstrukturen, für welche
Daten in der Speicherabbilddatei 36 enthalten sind.
-
2 gibt
einen Überblick über die
Schritte, die zum Analysieren der Daten innerhalb der Speicherabbilddatei 36 in
der veranschaulichenden Ausführungsform
durchgeführt
werden, die den Prinzipien der vorliegenden Erfindung treu ist.
Eine Speicherabbilddatei 36 wird vorgesehen (Schritt 44 in 2). Die Speicherabbilddatei 36 kann
von einem Speicher abgerufen werden oder kann im Fluge (on the fly)
erzeugt werden. Die Speicherabbilddatei 36 kann durch eine
Absturzprotokolleinrichtung oder durch eine Laufzeit-Abzugseinrichtung
erzeugt werden. Datentypdefinitionstemplates werden vorgesehen (Schritt 46 in 2). Diese Templates können entweder
im Voraus erzeugt oder im Fluge durch die Verarbeitung eines Computerprogramms
erzeugt werden, das der Speicherabbilddatei 36 zugeordnet ist.
In der veranschaulichenden Ausführungsform werden
Templates für
jede Programmquelldatei für eine
bestimmte Hauptversion des Programms erzeugt, und eine der Dateilisten 43 schafft
Querverweise zwischen den Datentypen auf der einen Seite und Templates
und Quelldateien auf der anderen Seite. Die Templates 37 werden
im Speicher 38 als ein Teil der Templatedatenbank gespeichert
(Schritt 48 in 2).
-
Der Compiler 32 wird zum
Erzeugen der Templates verwendet. Die entsprechenden Programmquelldateien
des Computerprogramms werden durch den Compiler 32 laufen
gelassen, der zum Erzeugen der Templates modifiziert wurde.
-
Der Compiler 32 sucht im
Computersystemtext nach reservierten Wörtern, die Datentypdefinitionen
entsprechen und extrahiert Information aus den Datentypdefinitionen
für die
Templates 37. Wenn das Computersystem 30 zum Beispiel in
der Programmiersprache C geschrieben ist, sucht der Compiler 32 nach
reservierten Wörtern
wie zum Beispiel #define, struc, enum, union, ⌷ und Funktionsdefinitionen, die
Objekte zurückgeben.
-
Ein Template
37 ist eine
kleine Repräsentierung
eines Datentyps, die direkt aus dem Quellcode des Computerprogramms
abgeleitet ist, wobei alle Hardware-Versions- und Patchabhängigkeiten
entfernt wurden. Es sei zum Beispiel die folgende Datentypdefinition
für einen
Datensatzdatentyp betrachtet (der in der Programmiersprache C geschrieben
ist):
-
Diese Datentypdefinition zeigt an,
dass der Datensatzdatentyp zwei Etiketten hat (d.h. "r_a" und "r_a2") des Datentyps "a", die jeweils die Größe N1 haben (die definierte
Größe für Daten
des Datentyps a auf dem Computersystem) und ein einziges Etikett (d.h. "r b") des Datentyps "b" der Größe N2 (die definierte Größe für Daten
des Datentyps b). Das Etikett r_a startet beim Versatz 0; das Etikett
r_b startet beim Versatz N1; und das Etikett r_a2 startet beim Versatz N1
+ N2.
-
Das Template für den oben definierten Datensatzdatentyp
ist wie folgt:
- 1. ein Etikett r_a des Typs
datatype_a
- 2. ein Etikett r_b des Typs datatype_b
- 3. ein Etikett r_a2 des Typs datatype_a
-
Das Template enthält keine Angabe bezüglich der
Größe oder
des Versatzes der Etiketten (da dies von der Hardwareplattform,
der Version oder einem Patch abhängen
kann).
-
Die Templates 37 können zusätzlich Information über den
Abschnitt des Quellcomputerprogramms enthalten, wo der Datentyp
definiert ist. Diese Information ist beim Anzeigen des Abschnitts
des Codes hilfreich, wenn dies vom Benutzer angefordert wird. Templates 37 können auch
Attribute enthalten, die Werte für
computersystemabhängige
Information in einer computersystemabhängigen Weise enthalten. Zum
Beispiel kann ein Seitendatentyp ein SPARCTM-Mikroprozessorattribut
haben, wenn es auf einer SPARC-Workstation von Sun Microsystems, Inc.
läuft,
und ein X86-Attribut, wenn es auf einer Maschine läuft, die
einen X86-Prozessor von Intel Corporation verwendet.
-
In der veranschaulichenden Ausführungsform
werden die Templates 37 aus jeder Quelldatei für eine bestimmte
Version des Betriebssystems 30 erzeugt. Die Dateilisten 43 werden
zum Schaffen von Querverweisen von Datentypen zu entsprechenden Templates
und zum Quellcode erzeugt. Eine der Dateilisten 43 enthält Information,
welche Querverweise für
jedes Template 37 zu seinem Datentyp schafft. Eine andere
der Dateilisten 43 schafft Querverweise für jeden
Datentyp zu dem Abschnitt des Quellcodes, der den Datentyp definiert.
Eine Patchdateiliste 43 enthält Querverweise zwischen Datentypen,
die durch Patches verändert
oder erzeugt wurden, und den zugeordneten Templates und Quellcodeabschnitten.
-
Der Fachmann wird erkennen, dass
die Dateilisten auch anders als oben erörtert organisiert sein können. Zum
Beispiel kann alle Information über Querverweise
in eine einzige Dateiliste integriert sein. Außerdem kann eine viel feinere
Granularität angewendet
werden, um eine viel größere Anzahl von
Dateilisten vorzusehen, wie zum Beispiel eine Dateiliste pro Datentyp.
Außerdem wird
der Fachmann erkennen, dass die Dateilisten 43 zur Umsetzung
der vorliegenden Erfindung nicht nötig sind; es können auch
andere Querverweismechanismen verwendet werden.
-
Die Templates 37 werden
verwendet, wenn eine Anforderung empfangen wird, eine Repräsentation
eines Datentyps innerhalb einer Speicherabbilddatei anzusehen (Schritt 50 in 2). Zum Beispiel kann ein
Benutzer das Ansehen von Daten eines bestimmten Datentyps anfordern.
Die veranschaulichende Ausführungsform
definiert Datentypobjekte zum Enthalten von Information über die
bestimmten Datentypen. Die Erzeugung der Datentypobjekte enthält das Binden
von Templates an die Objekte, so dass die computersystemunabhängige Information aus
den Templates zusammen mit computersystemabhängiger Information, die dynamisch
hinzugefügt wird,
den Datentypobjekten hinzugefügt
wird (Schritt 52 in 2).
-
3 zeigt
ein Fließdiagramm
der Schritte, die zum Binden eines Templates an ein Datentypobjekt
durchgeführt
werden. Anfänglich
wird der Name des Datentyps in einer Dateiliste 43 nachgeschlagen, um
ein Template aus dem Datentyp zu identifizieren (Schritt 58 in 3).
-
Die Analyseeinrichtung 34 untersucht
Information im Programmbetriebskontext (wie zum Beispiel den Typ
der Hardwareplattform, auf der das Computerprogramm läuft, die
Version des Computerprogramms und welche Patches installiert sind),
um das spezifischste Template zu bestimmen, das für die Speicherabbilddatei 36 korrekt
ist. Es sei zum Beispiel angenommen, dass Attribute wie zum Beispiel Größe und Ausrichtung
des Integer-Datentyps, je nach dem Satz von Eigenschaften der Hardwareplattform,
der Betriebssystemversion und ob ein Patch installiert ist, variieren.
In diesem Fall wird der Programmbetriebskontext konsultiert, um
die Hardwareplattform zu identifizieren, auf der das Computerprogramm
läuft,
um die Version des Betriebssystems zu identifizieren und um zu identifizieren,
ob ein bestimmter Patch installiert ist. Das der identifizierten Kombination
von Hardwareplattform, Computerprogrammversion und Patch zugeordnete
Template wird ausgewählt.
Es kann auch andere Fälle
geben, wo ein Datentyp durch die Variablen Hardwareplattform, Computerprogrammversion
oder Patches nicht beeinflusst wird. Außerdem können auch andere Datentypdefinitionen
nur durch eine dieser Variablen oder zwei dieser Variablen beeinflusst
werden. Allgemein wird beim oben beschriebenen Verfahren mit dem
allgemeinsten Template begonnen und identifiziert, ob es ein spezifischeres
Template für
den bestimmten Programmbetriebskontext gibt.
-
Die im Template enthaltene Information
wird dann in das Datentypobjekt geladen, das für den Datentyp erzeugt wird
(Schritt 60 in 3).
Das Format des Datentypobjekts wird unten noch näher beschrieben. Zum Beispiel
kann die Identität
der im Template enthaltenen Etiketten in das Datentypobjekt geladen werden.
Die Etiketten werden rekursiv verarbeitet, bis der Datentyp eines
jeden Etiketts ausschließlich in
Grundelemente aufgelöst
ist (Schritt 62 in 3). Beim
Analysieren eines jeden Etiketts wird das zugeordnete Template aufgerufen
und ein Skelettdatentypobjekt für
das Etikett wird in der gleichen Weise wie oben beschrieben erzeugt.
Wenn das Template für einen
aggregierten Datentyp ist, der zusätzliche Etiketten enthält, wird
der Vorgang rekursiv solange wiederholt, bis alle Skelettdatentypobjekte
in Grundelemente aufgelöst
wurden. Der Programmbetriebskontext enthält einen Satz von Datentypobjekten, welche
Grundelemente für
das Computersystem 10 repräsentieren. Nachdem die Analyseeinrichtung 34 ein
Grundelement erreicht hat, beginnt es rückwärts, die Skelettdatentypobjekte
in vollständige
Datentypobjekte umzuwandeln, indem Computersystemabhängigkeiten
aus dem Programmbetriebskontext angewendet werden. Die Information,
die hinzugefügt wird,
enthält
die Größe der Grundelemente,
die richtige Ausrichtung der Datentypen und dergleichen. Nachdem
der rekursive Vorgang abgeschlossen ist (siehe Schritt 62 in 3), ist eine vollständige computersystemabhängige Version
des Datentyps im Datentypobjekt 38 repräsentiert.
-
4 zeigt
das Format eines Datentypobjekts 38 im größeren Detail. Insbesondere
zeigt 4 die Attribute,
die dem Datentypobjekt 38 zugeordnet sind. Der Fachmann
wird erkennen, dass auch hier eine Anzahl von Methoden 86 dem
Datentypobjekt 38 zugeordnet sind. Das Namenattribut 68 identifiziert
den Namen des Datentypobjekts. Das Produktattribut 70 identifiziert
ein Produkt (d.h. eine Version) des Betriebssystems, in dem der
Datentyp definiert wurde. In Fällen,
wo der Datentyp durch ein Basisprodukt definiert wurde, hat das
Produktattribut 70 einen Wert von Null. Ein Patchattribut 72 identifiziert,
welcher Patch gegebenenfalls im zugeordneten Datentyp definiert
ist. In Fällen,
wo der Datentyp nicht durch einen Patch definiert war, hat das Patchattribut einen
Wert Null.
-
Das Eigenschaftenattribut 74 enthält ein Eigenschaftenobjekt,
das Eigenschaftsinformation über
den zugeordneten Datentyp enthält.
Das Dateilistenschlüsselattribut 78 enthält einen
Schlüsselwert,
der demjenigen entspricht, der in der Dateiliste enthalten ist,
welche den Ort des Typobjekts innerhalb des Speichers 28 identifiziert.
Das Quellschlüsselattribut 80 enthält einen
Wert, der den Schlüssel identifiziert,
der in einer zweiten Dateiliste verwendet wurde, welche den Ort
der Datentypdefinition im Quellcode des Betriebssystems identifiziert.
-
Der Zeiger auf das Etikettenlistenattribut 82 enthält einen
Zeiger auf ein Feld, das eine Etikettenliste darstellt. Jedes Attribut
oder Feld in der Datentypdefinition stellt ein getrenntes "Etikett" ("tag") dar. Diese Etiketten
sind in der Etikettenliste identifiziert. Für jedes Etikett ist eine Etikettendatenstruktur 88, wie
die in 5 gezeigte, in
der Etikettenliste vorgesehen. Diese Struktur 88 enthält den Namen 90 des Etiketts
sowie einen Zeiger auf die Typdefinition 92 für den zugeordneten
Datentyp. Ein Wert eines Versatzes 98, der den Versatz 94 des
Etiketts im Verhältnis
zur Basis des Datentyps identifiziert, ist enthalten. Im Etikett 96 enthaltener
Text wird zusammen mit einer Kopie der Flags 98 gespeichert.
Die Flags werden vom Flagsattribut 84 des Datentypobjekts 38 kopiert.
Die Flags identifizieren die Art der Typdefinition (d.h. ob sie
aus einem Feld, einer Datenstruktur, eine Vereinigung, einer Funktion,
einer Aufzählung,
einem Bid-Feld, einer lokalen Variable, einer globalen Variable,
einem Alias, einer konstanten Definition oder dergleichen stammen).
-
Die Datentypobjekte 38 können bei
der Initialisierung einer Analyseeinrichtung 34 oder zu
anderen Zeitpunkten erzeugt werden. In manchen Fällen kann die Analyseeinrichtung 34 so
konfiguriert werden, dass bestimmte Datentypobjekte bei der Initialisierung
und andere nach Bedarf erzeugt werden.
-
Die Datentypobjekte 38 werden
in Kombination mit der in der Symboltabelle 45 enthaltenen
Speicherabbildadresse verwendet, um die Datenobjekte 42 an
der angegebenen Speicheradresse zu konstruieren. Wie in 6 gezeigt ist, enthält jedes
Datenobjekt 100 eine Referenz 102 auf eine Adresse 106 in
der Speicherabbilddatei 36 und enthält ebenfalls eine Referenz 104 auf
ein Typobjekt 108, das in der Datenbank von Datentypobjekten 38 enthalten
ist. Die Referenzen 102 und 104 können die
Form von Zeigern annehmen. Das Datenobjekt 100 kann neben
den Referenzen auch noch andere Information enthalten. Das Datenobjekt 100 bindet
den Datentyp an die vorgegebenen Daten an der bestimmten Speicheradresse
in der Speicherabbilddatei 36. Das resultierende Datenobjekt 100 kann
cache-gespeichert werden, so dass es für jede nachfolgende Anforderung
nach der Repräsentierung
des Datentyps nicht wiederholt zu werden braucht. Das Datenobjekt 100 dient
zum Aufbau einer Zuordnung zwischen einem Teil der Speicherabbilddateidaten
und der Datentypobjekte 38. Das Datenobjekt 100 kann
symbolisch nach Information befragt werden oder aufgefordert werden,
ein anderes Datenobjekt als Instanz aufzurufen, auf das es referenziert
ist. Folglich kann ein symbolisches Programmierparadigma zum Zugreifen auf
die Daten in der Speicherabbilddatei 36 verwendet werden.
Daher kann das Datenobjekt 100 zum Eingehen auf die Anforderung
verwendet werden (Schritt 56 in 2).
-
Die Datenobjekte können zur
Entwicklung höherer
Objekte verwendet werden. Zum Beispiel sei angenommen, dass ein
Datenobjekt 42 auf eine bestimmte Instanz eines Threads
zeigt. Es kann sein, dass die Analyseeinrichtung 34 einem
Benutzer eine Liste der Threads im System anzeigen möchte. Zu diesem
Zweck kann die Analyseeinrichtung 34 ein Listenobjekt 116 erzeugen
(siehe 7), um verschiedene
Threads im System einzukapseln. Beim in 7 gezeigten Beispiel werden das Datenobjekt 110 für Thread 1,
Datenobjekt 112 für
Thread 2 und Datenobjekt 114 für Thread 3 in das
Listenobjekt 116 eingekapselt. Der Fachmann wird erkennen,
dass die höheren
Objekte nicht auf Listenobjekte eingeschränkt sein müssen, sondern beliebige andere
höhere
Objekte sein können,
wie zum Beispiel Felder und Datensätze. Außerdem können die Datenobjekte 42 zum
Erzeugen und Manipulieren anderer Typen von Objekten verwendet werden.
-
Einer der Vorteile der Analyseeinrichtung
der veranschaulichenden Ausführungsform
ist, dass sie zum Analysieren von Speicherabbildern für unterschiedliche
Programmquellen verwendet werden kann. Wie zum Beispiel in 8 gezeigt, sei angenommen,
dass die Version 1.0 eines Programms 118 einen Patch 126 und
eine Definition 122 eines Datentyps A enthält. Weiter
sei angenommen, dass eine Abzugseinrichtung 132 zum Erzeugen
eines Speicherabbilds 136 für das Computerprogramm 118 verwendet
wird. Das Speicherabbild enthält
Daten 140 des Datentyps A. Zusätzlich sei angenommen, dass eine
Version 2.0 des Computerprogramms 120 eine Definition 124 des
Datentyps A und eine unterschiedliche Version 128 des Patches
enthält.
Außerdem enthält diese
Version des Computerprogramms 120 einen zweiten Patch 130.
Diese Version des Computerprogramms 120 wird zum Erzeugen
eines zweiten Speicherabbilds 138 durch eine Abzugseinrichtung 134 laufen
gelassen. Das zweite Speicherabbild enthält Daten 142 des Datentyps
A. Trotz der Unterschiede der Computerprogramme 118 und 120 kann die
Analyseeinrichtung 144 zur Betrachtung der Daten 140 und 142 für den Datentyp
A verwendet werden. Die Größe, Ausrichtung
und andere Attribute des Datentyps A können bei den entsprechenden Computerprogrammen 118 und 120 variieren.
Trotzdem berücksichtigt
die Analyseeinrichtung 144 diese Variationen der Attribute.
Die Quellcomputerprogramme 118 und 120 unterscheiden
sich in der Version, den Patchversionen und darin, welche Patches angewendet
werden. Die Analyseeinrichtung berücksichtigt die Unterschiede.
-
9A zeigt
ein Hauptbetrachtungsfenster 150, das als ein Teil der
GUI von der Analyseeinrichtung 34 erzeugt wird. Das Hauptbetrachtungsfenster 150 dient
als das Grundfenster, durch das ein Benutzer durch die in der Speicherabbilddatei 36 enthaltenen
Daten navigieren kann. Das Hauptbetrachtungsfenster enthält eine
Anzahl von Icons 152, die zum Zugreifen auf verschiedene
Funktionen und Extensionen verwendet werden können, die durch die Analyseeinrichtung 34 bereitgestellt
werden. Eine Liste 154 von Optionen ist ebenfalls vorgesehen
und kann vom Benutzer ausgewählt
werden, um auf die aufgelisteten Funktionen und Extensionen zuzugreifen.
-
Das Hauptbetrachtungsfenster 150 kann
als ein Hilfsmittel zum Anzeigen von Daten aus der Speicherabbilddatei 36 für ein bestimmtes
Objekt verwendet werden. 9B zeigt
das Objektfenster 160, das in einem solchen Fall erzeugt
wird. Der Clientbereich 162 des Objektfensters 160 enthält Informationen über die verschiedenen
Etiketten, die Teil des Objekts sind. Jede Zeile von im Clientbereich 162 gezeigter
Information ist einem bestimmten Etikett zugeordnet, das Teil des
Objekts ist.
-
9C zeigt
ein Listenfenster 164. Das Listenfenster enthält Information über eine
Anzahl unterschiedlicher Objekte des gleichen Objekttyps. Im in 9C gezeigten Beispielfall
besteht das Objekt aus Threads und das Listenfenster 164 zeigt
Daten für
verschiedene Threads. Jeder Spalte sind entweder Etiketten oder
Informationen über
den zugeordneten Thread zugeordnet.
-
Zwar wurde die vorliegende Erfindung
anhand einer veranschaulichenden Ausführungsform beschrieben, doch
wird der Fachmann erkennen, dass verschiedene Änderungen in der Form und im Detail
vorgenommen werden können,
ohne dass dadurch vom beabsichtigten Umfang der vorliegenden Erfindung,
wie er in den nachfolgenden Ansprüchen definiert ist, abgewichen
wird. Zum Beispiel kann die vorliegende Erfindung nicht mit einem
Betriebssystem sondern vielmehr allgemeiner mit Systemcode oder
anderen Computerprogrammen praktiziert werden, für die das Analysieren einer
Speicherabbilddatei nützlich
sein kann. Das Betriebssystem braucht nicht das Solaris-Betriebssystem
sein, und der Compiler braucht kein C-Compiler oder C++-Compiler zu sein,
sondern kann vielmehr ein Interpretieren sein. Der Systemcode kann
zum Beispiel auch in der Programmiersprache JAVA geschrieben sein.
