Debugger Known Limitations

This document lists the Debugger current known limitations:

Execution
Variables
Step Into
Dialogs
Display
Expressions
Layout DXL
Triggers

Execution

When a modal dialog is open in the active DOORS client, it may happen that DOORS does not execute the DXL code it is instructed to run by DXL Editor. In this case, the debugger cannot suspend on a breakpoint as the DXL file is not executed at all, without DOORS informing DXL Editor about it. Note that not all DOORS modal dialogs produce this unexpected behavior. Still, recommendation is to close dialogs in DOORS by the time you request DXL Editor to run or debug a DXL file.

Variables

There are some variable patterns that are not handled at this time by the debugger. For such patterns, the corresponding variables won't be visible in the Variables view.
Note however that it does not impact the debugger execution.

Unhandled variables patterns:

Auto-declare
Auto-declared variables (sometimes referred as immediate declaration) are not recognized by the debugger.
Example: i = 5;

Workaround:
Please consider to explicitly declare your variables. Auto-declare is known to be a quite hazardous mechanism that may lead to errors that are hard to find (particularly in case of a typing mistake).
Example: int i = 5;

Unassigned variables

You may declare variables in your DXL code without yet assigning a value to the variable.
Early DOORS 64-bit client versions do not offer any reliable mean to detect whether a variable is unassigned.
Here is the compatibility matrix on this topic:

DOORS client	Architecture	Unassigned variables correctly detected?
All versions	32-bit	Yes.
9.6.1.6 and earlier	64-bit	No. If a variable is unassigned, the debugger will likely show `#ERROR#` in the Variables view. As a workaround, you are recommended to assign a value (e.g. `null`) to the variable by the time it is declared (e.g. `Module m = null;`).
9.6.1.7 and newer	64-bit	Yes.

Struct types
Only DOORS predefined types are recognized by the debugger. If you use a self-defined struct type, variables of such type won't be visible in the debugger.
Pointers
Pointer variables are not recognized by the debugger.
Example: string *s;
Array references
Array reference variables are not recognized by the debugger.
Example: string &s[];

Step Into

There are some DXL code locations that the debugger won't access. You won't be able to install breakpoints and to step into such locations.

Encrypted Files
Encrypted DXL files are by nature files that are not meant to be visible by DXL developers.

Addins paths overriden using DOORS command line
The debugger can analyze the DXL include statements and resolve them to absolute file paths (see Debugger Architecture). However if you override the Addins paths in the DOORS command line (using -addins, -projectaddins or -layoutaddins), the DXL Debugger won't be aware of these new locations. In that case you won't be able to step into functions defined in those locations.

Workaround:
Instead of directly launching doors.exe with a command line, you may create a new batch file containing the following statements:

SET ADDINS=<addinspath>
SET DOORSADDINS=<addinspath>
SET PROJECTADDINS=<projectaddinspath>
SET DOORSPROJECTADDINS=<projectaddinspath>
doors.exe

Using environment variables instead of command line switches, the DXL debugger will be able to access the overriden addins paths.

Note: If you change the addins paths in the Windows Registry, you must then restart DOORS and restart the DXL Editor as well.

Functions that return arrays
The debugger does not support functions that return arrays.
You are recommended to avoid using this type of construct since this usually creates memory bugs, when the array space is released after leaving the function.
Functions that return functions
The debugger does not support functions that return functions.
Code executed with eval_ function
The debugger does not support debugging statements in DXL code that is declared in a string and executed using the eval_ function.

Dialogs

Breakpoints and callbacks
Only one breakpoint can be hit a time. That means if the DXL execution is already suspended and a callback hits a breakpoint, this second breakpoint will be ignored by the IDE.
show(DB) replaced by block(DB)
When debugging, the show(DB) function is redefined to call block(DB). Without doing this, the debugger would consider the execution is terminated when a dialog box is displayed, and you would not be able to debug code invoked by dialog callbacks.
destroy(DB) called from callbacks
As stated in the DOORS DXL documentation, destroy(DB) should not be called from a callback. This is particularly true when using block(DB), which is what the debugger does (see previous item). Calling destroy(DB) from a callback can lead to platform unstability.

Display

There are some limitations in the display of stack frames and DXL variables:

Skip
The Variables view cannot display the content of a Skip. This is because the debugger has no information on the type of keys and of values of this Skip. Trying to display the Skip content without such information can result in DOORS crashing.

Workaround:
You can display the content of a Skip list using the Display view, with a DXL function provided by the debugger:
SkipContents(mySkip, keyType, valueType)

For example, if you have a Skip variable named mySkip, where keys are strings and values are modules:

Type the following expression: SkipContents(mySkip, "string", "Module")
Select the expression and right-click Display

Important Note: Using the wrong type for keys or values can make DOORS unstable.

Array
The Variables view cannot display the content of an Array. This is because the debugger has no information on the type of content within the Array. Trying to display the Array content without such information can result in DOORS crashing.
Function called in a return statement
When a function f2() is called in a return statement of a function f1(), suspending the execution inside f2() will not show f1() in the execution stack frames.

Expressions

There are some limitations in the type of expressions you can evaluate when the execution is suspended.

Function calls in expressions
You cannot call functions defined in the DXL file being debugged. You can only access DXL predefined functions.

Layout DXL

The DXL Debugger cannot be used to debug Layout DXL scripts, as such script requires a current Object to be pre-selected by DOORS.

Triggers

The DXL Debugger cannot be used to debug Triggers DXL scripts, as such script requires a trigger event to be pre-selected by DOORS.

Related concepts
Debugger