8 Dumpstate (Zustandsinformationen)

Verfügbarkeit

Die Dumpstate-Ausgabe steht für die DM Versionen A.05.01.g3 und A.05.01.h sowie ab A.05.02.e zur Verfügung.

Der Dumpstate ist eine Zustandsinformation von IDM-relevanten Informationen um die Fehleranalyse einer IDM-Applikation zu erleichtern.

Der Inhalt des Dumpstate ist in verschiedene Abschnitte unterteilt, die variabel und der Fehlersituation angepasst sind. Außerdem wird er von zuvor aufgetretenen Fehlern beeinflusst. Beispielsweise führt eine erfolglose Speicherallokierung bei der nächsten Dumpstate-Ausgabe dazu, dass Informationen bzgl. der Speichernutzung durch den IDM ausgegeben werden. Konnten keine IDM-Objekte oder Bezeichner mehr angelegt werden, wird die Auslastung von IDM-Objekten und Bezeichnern ausgegeben.

Die Dumpstate-Information ist immer zwischen *** DUMP STATE BEGIN *** und *** DUMP STATE END *** eingeschlossen und kann folgende, in den nächsten Unterabschnitten detailliert beschriebenen, Abschnitte aufweisen:

PROCESS: Prozess- und Thread-Nummer, Datum/Uhrzeit.
ERRORS: Kompletter Inhalt der gesetzten Fehlercodes.
CALLSTACK: Aufruf-Stack – beinhaltet Regeln, DM-Schnittstellenfunktionen und die obersten, vom IDM aufgerufenen, Applikationsfunktionen.
THISEVENTS und EVENT-QUEUE: Aktuell verarbeitete thisevent-Objekte und deren Werte sowie Ereignisse die noch in der Warteschlange stehen.
USAGE: Anzahl angelegter Objekte, Module und Bezeichner, Speichergröße die vom Regelinterpreter und für die String-Übergabe genutzt wird.
MEMORY: Speichernutzung die vom IDM erfassbar ist.
SLOTS: Hinweise zu IDM-Objekten die nicht richtig freigegeben wurden.
VISIBLE OBJECTS: Liste der sichtbaren Objekte mit ihren Werten.

Um die Ausgabe möglichst klein zu halten, erfolgt sie normalerweise in gekürzter Form. Grundsätzlich immer erfolgt eine Kürzung von IDM-Strings (in "…") auf maximal 40 Zeichen. Ihre Gesamtlänge wird in [ ] angehängt. Bytegrößen-Angaben erfolgen gekürzt auf Kilo-, Mega oder Gigabyte (k/m/g).

Der Dumpstate wird normalerweise automatisch in die Log- bzw Tracedatei herausgeschrieben wenn eine der in der folgenden Tabelle genannten Situationen eintritt. Dabei beeinflusst die Situation auch den Inhalt des Dumpstates.

Fehlerart	Ausgegebene Abschnitte
Der Regelinterpreter meldet einen EVAL ERROR.	Errorstack, Callstack, Events.
Die IDM-Bibliothek erkennt einen eigenen Fehler und meldet einen FATAL ERROR.	Alle.
Eine abfangbare Exception (z.B. Access Violation, Stack Overflow, Division by Zero) tritt auf und der IDM Exception-Catcher ist aktiv.	Alle, zusätzlich wird noch der Exception-Code (Microsoft Windows) bzw. die Signal-Nummer (Unix) vorneweg ausgegeben. Unter Unix wird ab IDM-Version A.05.02.e bei einem INT-Signal kein vollständiger Dumpstate mehr ausgegeben, sondern nur noch die Abschnitte Stack, Errors, Process und Events.
Normales Beenden über DM_ShutDown() aber Hinweise zu aufgetretenen Fehlern liegen vor.	Entsprechend den Hinweisen.

Wichtiger Hinweis

Sicherheitsrelevante Informationen, z.B. Passwörter, die in ein Login-Fenster eingegeben werden, sollten nach ihrer Verwendung von der Anwendung gelöscht werden, damit sie nicht über einen Dumpstate ausgegeben und dadurch zugänglich gemacht werden.

Das Schreiben des Dumpstate kann auch explizit durch die Builtin-Funktion dumpstate() bzw. die Schnittstellenfunktion DM_DumpState() erfolgen. Zusätzlich gibt es über die Optionen ‑IDMdumpstate und ‑IDMdumpstateseverity die Möglichkeit, die Ausgabe unabhängig von der Fehlerart zu beeinflussen bzw. die Fehlerart zu definieren, bei der eine Dumpstate-Ausgabe erfolgt.

In Anbetracht der großen Anzahl an komplexen Informationen, die beim Dumpstate ermittelt werden, kann ein Absturz innerhalb der Dumpstate-Funktionalität nicht abgefangen bzw. ausgeschlossen werden.

Es folgt eine detaillierte Beschreibung der einzelnen Abschnitte die im Dumpstate vorkommen.

8.1 Process

Dieser Bereich beinhaltet die Process-ID, die Nummer des Thread in dem der Dumpstate aufgerufen wird sowie die Thread-Nummer des IDM-Haupt-Thread. Wird der Dumpstate nicht im IDM-Haupt-Thread aufgerufen steht an erster Stelle der Hinweis:

ATTENTION: not in IDM main thread!

Dann ist Vorsicht geboten, deutet es doch auf einen Applikationsfehler, einen Fehler in einer externen Funktion oder die unsachgemäße Benutzung des IDM hin. Es ist zu beachten, dass der Callstack nur die Aufrufliste des IDM-Haupt-Thread beinhaltet!

PROCESS:
pid=2984, thread=4080, IDM-thread=4080, date=2009-11-10, time=16:20:38

8.2 Errors

Listet alle aktuell gesetzten Fehlercodes auf. Siehe hierzu auch Schnittstellenfunktion DM_QueryError im Handbuch „C-Schnittstelle - Funktionen“.

ERRORS:
#0: IDM-E-UnkAttr: Attribute not available for this type of object [object/thing:639]

8.3 Callstack

Der Callstack (Aufrufliste) ist das wichtigste Mittel um zu erkennen, ob bei einem Absturz ein Fehler in einer Applikationsfunktion, einer Regel oder Methode, in der IDM-Bibliothek oder einer externen Funktion aufgetreten ist.

Der Callstack beinhaltet alle Aufrufe von Regeln, Methoden, eingebauten Funktionen, DM-Schnittstellenfunktionen sowie die vom IDM aufgerufenen Applikationsfunktionen. Dazu werden die Parameterwerte ausgegeben. Allerdings kann nicht in jeder Situation eine korrekte String-Codierung vorgenommen werden, um Auswirkungen auf die Performanz möglichst gering zu halten.

Für Regeln werden zusätzlich das this-Objekt, der Dateiname in der sich die Regel befindet, für ASCII-Dialoge die Startzeile der Regel, sowie eine %-Angabe, welche die ungefähre Position im Zwischencode der Regel darstellt, mit ausgegeben. Für die oberste Regel auf dem Stack werden außerdem die Werte der lokalen Variablen (locvars-Liste) sowie der Inhalt des Werte-Stack (valstack), der für die Ausdrucksauswertung benötigt wird, aufgelistet.

STACK:
#0: rule D.AfterError, this=dialog D, file=dumping.dlg:68+39%
  locvars=[dialog D, "initvar2", nothing]
  valstack=[100]
#1: rule on dialog start, this=dialog D, file=dumping.dlg:78+35%
#2: DM_StartDialog(dialog D, null)

Kürzungen

Es werden nur die obersten 20 und untersten 20 Einträge aufgelistet

Wichtig

Findet sich die Meldung ATTENTION: not in IDM main thread! am Anfang der Dumpstate-Ausgabe ist Vorsicht geboten. Der Callstack zeigt nur den Aufruf-Stack des IDM-Haupt-Thread an!

8.4 Events

In diesem Abschnitt werden die aktuell abgearbeiteten Ereignisse (THISEVENTS) und die Ereignisse, die noch in einer Warteschlange (EVENT QUEUE) stehen und als nächstes abgearbeitet würden, aufgelistet.

Die Quelle (source) gibt dabei die Ereignisauslösung an: dialog, setval, destroy oder external. Sie gibt Aufschluss darüber, ob es sich um ein vom Anwender/System ausgelöstes Ereignis handelt, es durch eine Wertänderung eines Attributs ausgelöst wurde, es sich um das Zerstören eines Moduls oder um ein externes Ereignis handelt.

Das Objekt, das der Empfänger des Ereignisses ist, wird angezeigt, ebenso die Warteschlange, der Datenwert und die Argumente sowie bei THISEVENTS die spezifischen Attribute (z.B. .x, .y).

THISEVENTS:
#0: source=dialog, object=dialog D, event=start
EVENT QUEUE#1:
#0: source=dialog, object=window D.Wi, event=activate
#1: source=external, object=pushbutton D.Wi.Pb, data=1, args=["EvData"]

Kürzungen

Maximal 10 Ereignisse werden aufgelistet

8.5 Usage

Dieser Abschnitt ist aus drei Tabellen aufgebaut:

Informationen über die Anzahl der IDM-Objekte, deren Verteilung auf Defaults, Modelle und Instanzen, ihre Gesamtanzahl und deren ungefährer Speicherbedarf im IDM-Kern (nicht der dargestellten Oberflächenelemente). Diese Tabelle ist aufsteigend nach den Spalten alloc und count sortiert.
Informationen über Dialoge und Module. Die Anzahl aller Dialoge und Module wird ausgegeben sowie die Summe der darin enthalten Objekt-Slots, der für die Slotverwaltung benötigte Speicher, die Gesamtanzahl der Bezeichner und der dafür notwendige Speicherplatz. In den <maximum>-Zeilen werden die Dialoge bzw. Module mit den größten Werten in den einzelnen Spalten aufgeführt. Dadurch sind Dialoge bzw. Module leicht identifizierbar, bei denen keine Objekte mehr angelegt werden können oder deren Platz für Bezeichner knapp wird.
Die dritte Tabelle ist informativer Art und enthält Anzahl und Speichergröße der Regel-Frames, die vom Regelinterpreter genutzt werden, sowie Anzahl und Speichergröße von Puffern, die für das Speichern von Zwischenergebnissen benötigt werden.

              class  defaults    models instances     count     alloc
------------------- --------- --------- --------- --------- ---------
        thisevclass         0         0         1         1        84
          clipboard         0         0         1         1       100
         setupclass         0         0         1         1       140
        accelerator         1         1         2         4       336
             module         0         0         1         1       628
         pushbutton         1         0         1         2       752
             dialog         0         0         1         1       783
               text         1         1         7         9       828
           edittext         1         0         1         2       980
             window         1         1         1         3        2k
               rule         2         3         5        10       19k
            <total>         7         6        22        35       25k
 
   module     count     slots     alloc    labels labelsize name
--------- --------- --------- --------- --------- --------- -------------------
   dialog         1        27        3k        29        3k
   module         1         8        3k         1        3k
<maximum>                  27        3k        29        3k dialog D
 
   frames   f-alloc   scratch   s-alloc    values   v-alloc
--------- --------- --------- --------- --------- ---------
        2       22k         4        4k        69       17k

Die Spalten values und v-alloc der dritten Tabelle werden in den IDM-Versionen A.05.01.g3 und A.05.01.h nicht ausgegeben.

Kürzungen

Maximal 126 Klassen werden aufgelistet. Es werden keine Objektklassen-bezogenen Allokierungsgrößen ermittelt (Spalte enthält nur Nullen).

8.6 Memory

Dieser Abschnitt enthält die Größe des allokierten Heap-Speichers und gibt damit Anhaltspunkte über den Speicherverbrauch der gesamten Anwendung. Diese Funktionalität ist nur unter Windows oder mit eingeschaltetem IDM-Memory-Debugging verfügbar. Ermittelt wird die Summe der allokierten Speicherblöcke über HeapWalk() sowie zusätzlich über _heapwalk für die C-Runtime. Der vom IDM direkt genutzte Heap ist mit * markiert, der Default-Heap des Prozesses mit P.

MEMORY:
        heap     alloc     other
- ---------- --------- ---------
*        crt      386k       56k
  0x02CC0000        4k       61k
  0x02BA0000        5k      167k
  0x029C0000      386k      613k
  0x02A10000        9k       56k
  0x006F0000        7k      999k
  0x00340000       12k       52k
  0x00630000       11k       53k
P 0x007B0000      137k      797k
     <total>      568k        3m

Kürzungen

Maximal die ersten 20 Heaps werden angezeigt.

Hinweis

Es ist zu beachten, dass die Heaps auch IDM-fremde Speicherallokierungen beinhalten, die z.B. von der Applikationsfunktion, Systemroutinen oder externe Funktionen (DLL, In-Process-OLE-Control) genutzt werden.

8.7 Slots

Die Ausgabe der Slots dient vornehmlich dem Erkennen von Fehlern in der IDM-Bibliothek, die mit Referenzierung sowie Freigabe und Zerstören von Objekten zusammenhängen. Es werden Objekt-Slots aufgelistet, die nicht vollständig entfernt werden konnten oder verdächtig hohe Referenzierungs- und Locking-Zähler aufweisen.

SLOTS:
        slot       class       refs locks drop hull object
------------ ----------- ---------- ----- ---- ---- --------------------
[0x00020028]      window          1     1    1    0 window D.WINDOW:[1]

Kürzungen

Maximal 20 Slots werden aufgelistet. Alle gesperrten Slots werden ungekürzt ausgegeben.

Wird für die Dumpstate-Ausgabe die Startoption, Builtin- oder Schnittstellenfunktion mit dem Parameter dump_locked (siehe Startoption ‑IDMdumpstate <enum> im Kapitel „Startoptionen“) verwendet, werden zusätzlich alle Attributewerte von gesperrten (locked) Objekten ausgegeben. Attributwerte von Ressourcen, Regeln und Funktionen können nicht ausgegeben werden.

8.8 Visible Objects

In diesen Abschnitt werden alle sichtbaren Objekte herausgeschrieben inklusive der Werte ihrer vordefinierten Attribute und sichtbaren Kindobjekte. Der Abschnitt soll bei Darstellungsproblemen einen Abzug möglichst aller relevanten Objekte und Attribute liefern um dadurch beispielsweise Probleme schneller reproduzieren zu können.

VISIBLE OBJECTS:
window Wi {
  .repos_id "";
  .userdata nothing;
  .visible true;
  .sensitive true;
  .navigable true;
  .fgc null;
  .bgc null;
  .font null;
:
}

In den Modus dump_full und dump_uservisible (siehe Startoption ‑IDMdumpstate <enum> im Kapitel „Startoptionen“) werden alle sichtbaren Objekte ausgegeben, die direkt unter einem Dialog bzw. Modul hängen. Zu diesen Objekten werden alle vordefinierten und benutzerdefinierten Attribute inklusive aller sichtbaren oder unsichtbaren Kindobjekte und Kind-Records ausgegeben.

Grundsätzlich können keine Ressourcen, Regeln, Methoden und Funktionen ausgegeben werden.

Kürzungen

Nur die obersten sichtbaren Objekte werden ausgegeben, ohne Wert/Kindobjekte.

8.9 Beispiel

Konstellation

Eine IDM-Anwendung startet über C einen eigenen Thread, der nach etwa 10 Sekunden abstürzt, da er auf eine ungültige Speicheradresse zugreift. Im Thread werden etwa 5 x 10MB Speicher allokiert. Der IDM legt währenddessen laufend Fenster und Records an, wobei zwar die Fenster wieder zerstört werden, die Records aber nicht.

Das Ende der Logdatei sieht dann etwa wie folgt aus:

FATAL ERROR: Exiting due to exception 0xC0000005 (ACCESS VIOLATION)
*** DUMP STATE BEGIN ***

ATTENTION: not in IDM main thread!

PROCESS:
pid=3024, thread=5176, IDM-thread=4684, date=2009-11-16, time=16:58:52

STACK:
#0: create(window, dialog D, true)
#1: rule D.Test ("c-thread-access-violation"), this=dialog D, file=bad.dlg:78+40%
  valstack=["c-thread-access-violation", window, true]
#2: rule on extevent 1 , this=dialog D, file=bad.dlg:112+71%
#3: DM_EventLoop(null)
THISEVENTS:
#0: source=external, object=dialog D, data=1

USAGE:
              class  defaults    models instances     count     alloc
------------------- --------- --------- --------- --------- ---------
             record         1         0     24704     24705         0
             window         1         0         1         2         0
          clipboard         0         0         1         1         0
             dialog         0         1         1         2         0
             module         0         0         1         1         0
         setupclass         0         0         1         1         0
        thisevclass         1         0         1         2         0
        accelerator         1         0         3         4         0
           function         0         0         6         6         0
               rule         1         1         5         7         0
               text         1         6        16        23         0
            <total>         6         8     24740     24754         0

   module     count     slots     alloc    labels labelsize name
--------- --------- --------- --------- --------- --------- -------------------
   dialog         1     24745       99k        28        3k
   module         1         9        3k         1        3k
<maximum>               24745       99k        28        3k dialog D

   frames   f-alloc   scratch   s-alloc
--------- --------- --------- ---------
        2       13k         5        5k
 
VISIBLE OBJECTS:
#0: window D.WiMain

MEMORY:
        heap     alloc     other
- ---------- --------- ---------
*        crt       11m        3m
  0x030D0000        4k       61k
  0x030E0000        5k      167k
  0x00300000       11k       54k
  0x02EF0000       11m        4m
  0x027A0000        6k       58k
  0x00030000       13k       52k
P 0x00A50000       48m      791k
     <total>       59m        5m

*** DUMP STATE END ***

Aus der Dumpstate-Ausgabe kann man folgendes ablesen:

Die Meldung ATTENTION: not in IDM main Thread! besagt, dass der Absturz (ACCESS VIOLATION) nicht im IDM passiert. Daher ist der Callstack in dieser Situation unverdächtig. Als es zu dem Absturz im anderen Thread kam, befand sich der IDM im Aufruf der Builtinfunktion create.
Die Anzahl der record-Instanzen im USAGE-Abschnitt ist verdächtig hoch. Dies ist in der record-Zeile der class-Tabelle sowie in der <maximum>-Zeile der module-Untertabelle erkennbar. Es spiegelt sich außerdem als hoher Speicherbedarf in der crt-Zeile der MEMORY-Tabelle wieder.
Die MEMORY-Tabelle zeigt, dass sich im Default-Heap des Prozesses (durch P gekennzeichnet) ein erheblicher Speicherverbrauch von über 50MB angesammelt hat.

8.10 Besonderheiten Windows/Threads

Der IDM verwaltet einen eigenen Callstack für Regelaufrufe, Methoden, eingebaute Funktionen, DM-Schnittstellenfunktionen und DM-Applikationsfunktion (siehe auch Kapitel „Callstack“). Für DM-Schnittstellenfunktionen (außer DM_SendEvent, DM_QueueExtEvent, die nicht auf dem Callstack erscheinen) findet eine Überprüfung statt, ob sie aus demselben Thread aufgerufen werden in dem der IDM initialisiert wurde. Ist dies nicht der Fall erfolgt die Ausgabe einer Fehlermeldung.

Bis auf wenige Ausnahmen sind der IDM und seine Schnittstellen nicht für die Nutzung in Multi-Threaded-Situationen ausgelegt. Auch der Callstack dient nur zur Verwaltung IDM-spezifischer Funktionalität und nicht für beliebige Applikationsfunktionen.