8 Dumpstate (Status Information)

Availability

The dumpstate output is available in the IDM versions A.05.01.g3 and A.05.01.h as well as from A.05.02.e.

The dumpstate is the status information of IDM-relevant information in order to simplify the error analysis within an IDM application. The content of the dumpstate is divided into different sections that are variable and that are adapted to the error situation. In addition, the dumpstate is influenced by the errors that have previously occurred. For example an unsuccessful memory allocation leads to information concerning the memory usage by the IDM in the next dumpstate output. If no IDM objects or identifiers can be created, then the utilization of IDM objects and identifiers is dumped.

The dumpstate information is always encased between *** DUMP STATE BEGIN *** and *** DUMP STATE END *** and can have the following sections, which are described in detail in the paragraphs below:

PROCESS: Process and thread number, date/time.
ERRORS: Complete content of set error codes.
CALLSTACK: Contains rules, DM interface functions and application functions directly called by the IDM.
THISEVENTS and EVENT QUEUE: Actual 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.

In order to keep the output to a minimum, this is usually displayed in a shortened form. Normally, a shortening of the IDM strings (in "…") to a maximum of 40 characters always occurs. Their entire length is attached in [ ]. Byte size information is given in kilo, mega or gigabytes (k/m/g).

The dumpstate is normally automatically written to the log file or the trace file when one of the following situations occurs. Hereby, the situation also influences the dumpstate content.

Error Type	Dumped Sections
The rule interpreter delivers an EVAL ERROR.	Errorstack, Callstack, Events.
The IDM library recognizes an error of its own and delivers a FATAL ERROR.	All.
An catchable exception (e.g. access violation, stack overflow, division by zero) comes about and the IDM exception catcher is active.	All – in addition, the exception code (Microsoft Windows) or the signal number (Unix) is initially displayed. On Unix since IDM version A.05.02.e no complete dumpstate is output after an INT signal anymore, but only the sections Stack, Errors, Process and Events.
Normal shutdown via DM_ShutDown() but information about errors are at hand.	According to the hints.

Important Note

Safety-related information, for example passwords that are typed in a log-in window, should be deleted after being used by the application, so that they cannot be output in a dumpstate and thus be exposed.

The writing of the dumpstate can explicitly take place via the builtin function dumpstate() or the interface function DM_DumpState(). In addition, it is also possible to influence the dumpstate output independent of the type of error or to define the type of error in which a dumpstate output takes place via the options ‑IDMdumpstate and –IDMdumpstateseverity.

Due to the amount of complex information that is gathered by the dumpstate, crashes within the dumpstate functionality can happen and cannot be intercepted.

The following contains a detailed description of the various sections that can be found in the dumpstate:

8.1 Process

This area contains the process ID, the number of the thread in which the dumpstate is called as well as the thread number of the IDM main thread. If the dumpstate is not called from the IDM main thread, then the following message is displayed:

ATTENTION: not in IDM main thread!

When this happens extreme care should be taken. This indicates either an application error, an error in an external function or the improper use of the IDM. Please note that the callstack only contains the call list of the IDM 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 callstack (call list) is the most important tool in order to recognize if the reason behind a system crash is due to an error that occurred in an application function, in a rule or method, in the IDM library or in an external function.

The callstack contains all calls of rules, methods, built-in functions, IDM interface functions as well as the application functions called by the IDM. Hereby, the parameter values are displayed. However, in order to minimize the effect on performance it is not possible to carry out a correct string coding in every situation.

In addition, the this-object, the file name in which the rule is found, for ASCII dialogs the start-line of the rule as well as a %-output, which delivers the approximate position in the intermediate code of the rule, is also included. For the first rule on the stack the local variables (locvars list) as well as the content of the value stack (valstack), which is necessary for the expression evaluation, is 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)

Abridgements

Only the first 20 and the last 20 entries are listed.

Important

If the message ATTENTION: not in IDM main thread! appears at the beginning of the dumpstate output, extreme care should be taken. The callstack only displays the callstack of the IDM main thread!

8.4 Events

In this section the actual processed events (THISEVENTS) and the events that are currently waiting in line (EVENT QUEUE) to be processed are listed.

The source indicates the event trigger: dialog, setval, destroy or external. This reveals whether this has to do with an event that was triggered by a user or the system, if it was triggered by a change in value of an attribute, if it has to do with the destruction of a module or if it has to do with an external event.

The object, which is the recipient of the event, is also shown. The event queue, the data value and the arguments as well as the specific attributes of THISEVENTS (e.g. .x, .y) are also displayed.

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"]

Abridgements

A maximum of 10 events are listed

8.5 Usage

This section is made up of three tables:

Information concerning the number of IDM objects, their distribution on defaults, models and instances, their total number and their approximate memory need in the IDM core (not the displayed user interface elements). This table is sorted in an ascending order in the columns alloc and count.
Information pertaining to dialogs and modules. The number of all dialogs and modules is displayed. Furthermore, the sum of the object slots contained in the dialogs and modules, the memory that is needed for the slot administration, the complete number of identifiers and the memory needed for this is also shown. In the <maximum> line the dialogs and modules with the largest values are listed in the individual columns. This makes the dialogs and modules, upon which no further objects can be created or whose space for identifiers is becoming scarce, easier to identify.
The third table is of an informative nature and contains the number and the memory size of the rule frames that are used by the rule interpreter. It also contains information pertaining to the number and memory size of buffers that are necessary for the storage of interim 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

The columns values and v-alloc of the third table are not output in the IDM versions A.05.01.g3 and A.05.01.h.

Abridgements

A maximum of 126 classes are listed. No object class-related allocation sizes are determined (column contains only zeros).

8.6 Memory

This section contains the size of the allocated heap storage and gives clues about the amount of memory used for the entire application. This functionality is only available under Windows or with an activated IDM memory debugging. The sum of the allocated memory blocks is determined via HeapWalk() and for the C-runtime via _heapwalk. The heap that is used directly by the IDM is marked with * and the default heap of the process is marked 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

Abridgements

Only the first 20 heaps are displayed.

Note

Please be aware that the heaps also contain IDM-foreign memory allocations that are, for example, used by the application function, system routines or external functions (DLL, In-Process-OLE-Control).

8.7 Slots

The output of slots serves especially for the recognition of errors in the IDM library, which are related to the referencing, the release and the destruction of objects. A list of object slots, which could not be completely eliminated or that displayed suspiciously high referencing and locking counters, is created.

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

Abridgements

A maximum of 20 slots is listed. All locked slots are displayed in full.

If the command line option, bulit-in or interface function with the parameter dump_locked (see command line option ‑IDMdumpstate <enum> in chapter “Command Line Options”) is used for the dumpstate output, then additionally all attributes of the locked objects are dumped. Attribute values of resources, rules and functions cannot be dumped.

8.8 Visible Objects

In this section all of the visible objects are written out including the values of their pre-defined attributes and visible child objects. This section should deliver copies of most of the relevant objects and attributes when display problems occur in order to be able to reproduce errors more quickly.

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

In the dump_full and dump_uservisible mode (see command line option ‑IDMdumpstate <enum> in chapter “Command Line Options”) all visible objects that are directly attached under a dialog or a module are written out. All of the pre-defined and user-defined attributes including all of the visible and invisible child objects and child records are written out for these objects.

In principle no resources, rules, methods or functions can be dumped.

Abridgements

Only the top visible objects are dumped, without value/child objects.

8.9 Example

Constellation

An IDM application started an individual thread via C that crashed after 10 seconds because it was trying to access an invalid storage address. In the thread approximately 5 x 10MB memory is allocated. During this process the IDM is constantly creating windows and records whereby the windows are eventually destroyed, but not the records.

In this case the end of the log file looks somewhat like the following:

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 can be read from the dumpstate output:

The message ATTENTION: not in IDM main Thread! implies that the crash (ACCESS VIOLATION) does not take place in the IDM. For this reason the callstack is, in this situation, unsuspicious. When the crash occurred in another thread the IDM was calling the built-in function create.
The number of record instances in the USAGE section is suspiciously high. This can be seen in the record line of the class table as well as in the <maximum> line of the module sub-table. In addition, the enormous storage need is reflected in the crt line of the MEMORY table.
The MEMORY table shows that an enormous amount of memory (over 50 MB) has been accumulated in the default heap of the process (labeled as P).

8.10 Noteworthy for Windows/Threads

The IDM manages its own callstack for rule calls, methods, builtin functions, IDM interface functions and IDM application functions (see also chapter “Callstack”). For the IDM interface functions (except for DM_SendEvent, DM_QueueExtEvent, which do not appear on the callstack) a check takes place to see if they are called from the same thread in which the IDM was initialized. If this is not the case, then an error message is sent.

For the most part (with only a few exceptions) the IDM and its interfaces are not designed for use in multi-threading situations. The callstack only serves to manage IDM-specific functions and not for arbitrary application functions.