7 Functions for Error Analysis

Availability

The functions for error analysis described in this chapter are available in the IDM versions A.05.01.g3 and A.05.01.h as well as from A.05.02.e

7.1 Overview

The purpose of the functions described here is to further assist the developer in the analysis and classification of errors in special situations such as: interpreter error messages, application crashes1 or fatal error messages. The following table contains a rough classification of possible errors in relation to typical points of error and the likely impact of such errors. The effect that an error remains undetected, leads to a changed or faulty functionality or may be transferred onto another component, is not explicitly mentioned in the table.

Point of Error	Description	Impact
Rule Code	Error in rule code of an IDM application, e.g. invalid access to an attribute or object, type errors or uninitialized values.	*** Eval Error in log or trace file [E: …] or [W: …] messages, YE- error codes in trace file
Application Function	Several error types, e.g. access violations, damaged memory management that in some cases may show through their impacts on the rule processing or the IDM library.	eventual crash
IDM Library	Faulty conditions within the IDM are normally secured through an assertion. However, an error can have an effect on the rule processing or it can appear as an application error.	FATAL ERROR in log or trace file [E: …] or [W: ..] messages in trace file
External Functions	External, IDM-independent functions, e.g. in a different thread or different library, can contain errors which can then be brought into other areas via actions such as overwriting memory or faulty synchronization.	e.g. crash

In the following further information pertaining to the new additions for easier error analysis and their purpose can be found.

Notes

In principle the new additions are not meant to replace or substitute a debugger or a tool such as Dr. Watson on Microsoft Windows. They are to be seen as add-ons in order to deliver meaningful information that cannot be delivered by the mentioned tools.
If previous serious errors have already occurred, then the correctness of the given information cannot be completely guaranteed.

7.1.1 Safety Tracing

In order to use the tracing function within the IDM for situations, in which application errors occur only after a longer period of time, the safety tracing mode can be used.

Normally, if the tracing function is running alongside application use this can lead to a decrease in performance and to a very large, cumbersome trace file. In the safety mode the tracing takes place in a ring buffer with a limited number of lines and line lengths thatis kept in the main memory. The buffer is then written in the trace file only after an application has been ended or after an error event.

Further information about safety tracing can be found with the comand line options ‑IDMstrace, ‑IDMstracefile and ‑IDMstraceopts in chapter “Command Line Options” and in chapter “Safety Tracing”.

7.1.2 Dumpstate

Without tracing, the user receives no clues when crashes, FATAL ERROR or Error in Eval messages occur in applications that use binary files and the IDM runtime library. The dumpstate reveals status information of the IDM specifics which include the callstack, the errorstack, events and hints pertaining to the number of IDM objects and the use of memory through the IDM.

The primary goal is to output as much information as possible when an error occurs in order to be able to properly assess the error and at the same time simplify the causal research. Only information that is known to the IDM can be gathered; no information pertaining to the application or foreign functions. The writing of the dumpstate can be programmatically achieved via the Rule Language or the DM interface function.

Important Note

Security-related information, e.g. passwords that are entered into a log-in window, should be deleted by the application immediately after they have been used so that they cannot be revealed through a dumpstate and as a result be made accessible to others.

Further information about dumpstate output can be found with the command line options ‑IDMcallstack, ‑IDMdumpstate and ‑IDMdumpstateseverity in chapter “Command Line Options” and in chapter “Dumpstate (Status Information)”.

7.2 Exception Catcher

In order to be able to write out the safety tracing as well as the dumpstate after a crash, a global exception catcher is registered for the application. The exception catcher passes on the exception in order to allow for its further usual processing through the operating system (core dump on Unix/Linux or the writing of a dump file on Microsoft Windows via Dr. Watson).

Note

When installing own exception catchers, please ensure that they pass on the exceptions.

The registration of an exception catcher can be prevented through the command line option ‑IDMcatchexceptions (see chapter “Command Line Options”).