8 Dumpstate (State Information)
Availability
The dumpstate output is available for DM versions A.05.01.g3 and A.05.01.h as well as from A.05.02.e onwards.
The dump state is a status information of IDM-relevant information to facilitate the error analysis of an IDM application.
The content of the dumpstate is divided into various sections, which are variable and adapted to the error situation. It is also influenced by previously occurring errors. For example, an unsuccessful memory allocation will result in the next dumpstate output displaying information regarding memory usage by the IDM. If no further IDM objects or identifiers could be created, the utilization of IDM objects and identifiers will be displayed.
The dump state information is always enclosed between *** DUMP STATE BEGIN *** and *** DUMP STATE END *** and can contain the following sections, which are described in detail in the following subsections:
- PROCESS: Process and thread number, date/time.
- ERRORS: Complete content of the error codes set.
- CALLSTACK: Contains rules, IDM interface functions and application functions directly called by the IDM.
- THISEVENTS and EVENT QUEUE: Currently processed thisevent objects and their values as well as events that are still in the queue.
- USAGE: The number of created objects, modules and identifiers and the size of the memory that is used by the rule interpreter and for string transfer.
- MEMORY: Memory usage as far as it can be detected by the IDM.
- SLOTS: Hints about IDM objects that have not been correctly released.
- VISIBLE OBJECTS: A list of the visible objects and their respective values.
- WSI: Additional information about WSI (Monitor information or resource consumption).
To keep the output as small as possible, it is usually displayed in abbreviated form. IDM strings (enclosed in "…") are always truncated to a maximum of 40 characters. Their total length is appended in [ ]. Byte sizes are abbreviated to kilobytes, megabytes, or gigabytes (k/m/g).
The dump state is normally written automatically to the log or trace file when one of the situations listed in the following table occurs. The situation also influences the content of the dump state.
|
Error type |
Issued sections |
|---|---|
|
The rule interpreter reports an EVAL ERROR. |
Errorstack, Callstack, Events. |
|
The IDM library detects an internal error and reports a |
All. |
|
A catchable exception (e.g. Access Violation, Stack Overflow, Division by Zero) The event occurs and the IDM Exception Handler is active. |
All of them, plus the exception code () or the signal number (Unix) issued in advance. Under Unix, as of IDM version A.05.02.e, an INT signal no longer outputs a complete dump state, but only the Stack, Errors, Process and Events sections. |
|
Normal shutdown via DM_ShutDown() was successful, but there are indications of errors that occurred. |
As per the instructions. |
Important Note
Security-relevant information, such as passwords entered into a login window, should be deleted by the application after use to prevent it from being exposed via a dump state and thus made accessible.
Writing the dump state can also be done explicitly using the built-in function dumpstate() or the interface function DM_DumpState(). Additionally, the options -IDMdumpstate and -IDMdumpstateseverity allow you to influence the output independently of the error type or to define the error type that triggers dump state output..
Given the large amount of complex information gathered during dumpstate operation, a crash within the dumpstate functionality cannot be prevented or ruled out..
The following is a detailed description of the individual sections that occur in the dump state.
8.1 Process
This section contains the process ID, the number of the thread in which the dump state is called, and the thread number of the IDM main thread. If the dump state is not called in the IDM main thread, the following information is displayed first:
ATTENTION: not in IDM main thread!
Caution is advised, as this indicates an application error, a fault in an external function, or improper use of the IDM. It's important to note that the call stack only contains the call list of the IDM's main thread!
PROCESS: pid=2984, thread=4080, IDM-thread=4080, date=2009-11-10, time=16:20:38
8.2 Errors
Lists all currently set error codes. See also interface function. DM_QueryError in manual “C Interface - Functions”.
ERRORS: #0: IDM-E-UnkAttr: Attribute not available for this type of object [object/thing:639]
8.3 Callstack
The call stack is the most important means of identifying whether a crash was caused by an error in an application function, a rule or method, in the IDM library, or in an external function.
The call stack includes all calls to rules, methods, built-in functions, DM interface functions, and application functions called by the IDM. Parameter values are also output. However, correct string encoding is not always possible in order to minimize the impact on performance.
For rules, the output also includes the this object, the filename containing the rule, and, for ASCII dialogs, the starting line of the rule and a percentage value representing its approximate position in the rule's intermediate code. For the topmost rule on the stack, the values of the local variables (locvars list) and the contents of the value stack (valstack), required for expression evaluation, are also listed.
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)
Shortages
Only the top 20 and bottom 20 entries are listed.
Important
If the message "ATTENTION: not in IDM main thread!" appears at the beginning of the dumpstate output, caution is advised. The call stack only displays the call stack of the IDM main thread!
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"]
Shortages
A maximum of 10 events will be listed.
8.5 Usage
This section is structured as three tables:
- Information about the number of IDM objects, their distribution across defaults, models, and instances, their total number, and their approximate memory requirements in the IDM core (not the displayed user interface elements). This table is sorted in ascending order by the alloc and count columns.
- Information about dialogs and modules. The total number of dialogs and modules is displayed, along with the total number of object slots they contain, the memory required for slot management, the total number of identifiers, and the memory required for them. The dialogs and modules with the highest values in each column are listed in the <maximum> rows. This makes it easy to identify dialogs and modules where no more objects can be created or where identifier space is running low.
- The third table is informative and contains the number and storage size of the rule frames used by the rule interpreter, as well as the number and storage size of buffers needed to store intermediate results.
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.
Shortages
A maximum of 126 classes are listed. No object class-related allocation values are determined (column contains only zeros).
8.6 Memory
This section contains the size of the allocated heap memory and thus provides an indication of the memory consumption of the entire application. This functionality is only available under Windows or with IDM memory debugging enabled. The total number of allocated memory blocks is determined using HeapWalk() and additionally using _heapwalk for the C runtime. The heap directly used by the IDM is marked with *, the process's default heap with 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
Shortages
Hinweis
It should be noted that the heaps also include non-IDM memory allocations, which are used, for example, by application functions, system routines, or external functions (DLL, In-Process OLE Control).
8.7 Slots
The output of the slots primarily serves to detect errors in the IDM library related to referencing, releasing, and destroying objects. It lists object slots that could not be completely removed or that exhibit suspiciously high referencing and locking counters.
SLOTS:
slot class refs locks drop hull object
------------ ----------- ---------- ----- ---- ---- --------------------
[0x00020028] window 1 1 1 0 window D.WINDOW:[1]
Shortages
A maximum of 20 slots are listed. All blocked slots are displayed in full.
If the startup option, built-in, or interface function with the parameter dump_locked (see startup option ‑IDMdumpstate <enum> in the "Command Line Options" chapter) is used for dumpstate output, all attribute values of locked objects are also output. Attribute values of resources, rules, and functions cannot be output.
8.8 Visible Objects
This section lists all visible objects, including the values of their predefined attributes and visible child objects. In case of display problems, this section is intended to provide a summary of as many relevant objects and attributes as possible, thus enabling faster reproduction of issues.
VISIBLE OBJECTS:
window Wi {
.repos_id "";
.userdata nothing;
.visible true;
.sensitive true;
.navigable true;
.fgc null;
.bgc null;
.font null;
:
}
In dump_full and dump_uservisible modes (see the startup option ‑IDMdumpstate <enum> in the "Command Line Options" chapter), all visible objects directly attached to a dialog or module are output. All predefined and user-defined attributes of these objects, including all visible or invisible child objects and child records, are also output.
In principle, no resources, rules, methods, or functions can be output.
Shortages
Only the topmost visible objects are displayed, without values/child objects.
8.9 WSI
This section provides information about monitor/screen configuration on all platforms. It is also used under Microsoft Windows to monitor the consumption of GDI and User objects. This allows object consumption to be checked in order to recognize early on when consumption reaches a critical level..
Also see .wsi_usage[enum],
The startup option -IDMwsiusagewarn can be configured to issue a notification when a limit value is reached.
WSI: comctl32 6.16.10586.8457, platformid=2, visual styles enabled dpi awareness: on (real: on), system dpi = 144 (real: 144), primary dpi = 144 (real: 144) wsi-counter used (%max) peak (%max) ------------ -------------- -------------- gdi objects 460 ( 5%) 475 ( 5%) user objects 339 ( 3%) 344 ( 3%) handles 275 monitor idm_x idm_y idm_w idm_h real_x real_y real_w real_h dpi ------- ------- ------- ------- ------- ------- ------- ------- ------- ------- 0 2560 0 1536 912 3840 0 3840 2280 240 * 1 0 0 2560 1392 0 0 3840 2088 144 virtual 0 0 4096 1392 0 0 7680 2280 144
8.10 Example
Constellation
An IDM application starts its own thread in C, which crashes after about 10 seconds because it accesses an invalid memory address. The thread allocates approximately 5 x 10MB of memory. During this time, the IDM continuously creates windows and records; while the windows are subsequently destroyed, the records remain intact.
The end of the log file then looks something like this:
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 ***
The following information can be gleaned from the dumpstate output:
- The message ATTENTION: not in IDM main Thread! indicates that the crash (ACCESS VIOLATION) did not occur in the IDM. Therefore, the call stack is not at fault in this situation. When the crash occurred in the other thread, the IDM was in the process of calling the built-in function create.
- The number of record instances in the USAGE section is suspiciously high. This is evident in the record row of the class table and in the <maximum> row of the module subtable. It is also reflected as high memory usage in the crt row of the MEMORY table.
- The MEMORY table shows that a significant memory consumption of over 50MB has accumulated in the process's default heap (marked by
P
).
8.11 Windows/Threads Special Features
The IDM manages its own call stack for rule calls, methods, built-in functions, DM interface functions, and DM application functions (see also the "Call Stack" chapter). For DM interface functions (except DM_SendEvent and DM_QueueExtEvent, which do not appear on the call stack), a check is performed to ensure they are called from the same thread in which the IDM was initialized. If not, an error message is displayed.
With few exceptions, the IDM and its interfaces are not designed for use in multi-threaded situations. The call stack also serves only to manage IDM-specific functionality and not for arbitrary application functions.
Support