To use Debugger, the basic steps are as follows:
Step 1. Start Debugger by calling
The
Step 2. Select Module > Interpret... in the Monitor window.
The
Step 3. Select the appropriate modules from the Interpret Dialog window.
Only modules compiled with option
Step 4. In the Monitor window, select Module > the module to be interpreted > View.
The contents of the source file is displayed in the
Step 5. Set the
Step 6. Start the program to be debugged. This is done the normal way from the Erlang shell.
All processes executing code in interpreted modules are displayed in the Monitor window.
Step 7. To attach to one of these processes,
double-click it, or select the process and then choose
Process > Attach. Attaching to a process opens an
Step 8. From the Attach Process window, you can control the process execution, inspect variable values, set breakpoints, and so on.
Once the appropriate modules are interpreted, breakpoints can be set at relevant locations in the source code. Breakpoints are specified on a line basis. When a process reaches a breakpoint, it stops and waits for commands (Step, Skip, Continue ...) from the user.
When a process reaches a breakpoint, only that process is stopped. Other processes are not affected.
Breakpoints are created and deleted using the Break menu of either the Monitor window, View Module window, or Attach Process window.
To have an effect, a breakpoint must be set at an
executable line, which is a line of code containing an
executable expression such as a matching or a function call.
A blank line or a line containing a comment, function head, or
pattern in a
In the following example, lines 2, 4, 6, 8, and 11 are executable lines:
1: is_loaded(Module,Compiled) -> 2: case get_file(Module,Compiled) of 3: {ok,File} -> 4: case code:which(Module) of 5: ?TAG -> 6: {loaded,File}; 7: _ -> 8: unloaded 9: end; 10: false -> 11: false 12: end.
A breakpoint can be either active or inactive. Inactive breakpoints are ignored.
Each breakpoint has a trigger action that specifies what is to happen when a process has reached it (and stopped):
A line breakpoint is created at a certain line in a module.
Right-click the Module entry to open a popup menu from which the appropriate module can be selected.
A line breakpoint can also be created (and deleted) by double-clicking the line when the module is displayed in the View Module window or Attach Process window.
A conditional breakpoint is created at a certain line in the module, but a process reaching the breakpoint stops only if a specified condition is true.
The condition is specified by the user as a module name
Right-click the Module entry to open a popup menu from which the appropriate module can be selected.
Example:
A conditional breakpoint calling
Extract from
5. fac(0) -> 1; 6. fac(N) when N > 0, is_integer(N) -> N * fac(N-1).
Definition of
-module(c_test). -export([c_break/1]). c_break(Bindings) -> case int:get_binding('N', Bindings) of {value, 3} -> true; _ -> false end.
A function breakpoint is a set of line breakpoints, one at the first line of each clause in the specified function.
To open a popup menu from which the appropriate module can be selected, right-click the Module entry.
To bring up all functions of the module in the listbox, click the OK button (or press the Return or Tab key) when a module name has been specified,.
The Erlang emulator keeps track of a stack trace, information about recent function calls. This information is used if an error occurs, for example:
1> catch a+1. {'EXIT',{badarith,[{erlang,'+',[a,1],[]}, {erl_eval,do_apply,6,[{file,"erl_eval.erl"},{line,573}]}, {erl_eval,expr,5,[{file,"erl_eval.erl"},{line,357}]}, {shell,exprs,7,[{file,"shell.erl"},{line,674}]}, {shell,eval_exprs,7,[{file,"shell.erl"},{line,629}]}, {shell,eval_loop,3,[{file,"shell.erl"},{line,614}]}]}}
For details about the stack trace, see section
Debugger emulates the stack trace by keeping track of recently called interpreted functions. (The real stack trace cannot be used, as it shows which functions of Debugger have been called, rather than which interpreted functions.)
This information can be used to traverse the chain of function
calls, using the Up and Down buttons in the
By default, Debugger only saves information about recursive function calls, that is, function calls that have not yet returned a value (option Stack On, No Tail).
Sometimes, however, it can be useful to save all calls, even tail-recursive calls. This is done with option Stack On, Tail. Notice that this option consumes more memory and slows down execution of interpreted functions when there are many tail-recursive calls.
To turn off the Debugger stack trace facility, select option Stack Off.
If an error occurs, the stack trace becomes empty in this case.
For information about how to change the stack trace option, see
section
The Monitor window is the main window of Debugger and displays the following:
A listbox containing the names of all interpreted modules
Double-clicking a module brings up the View Module window.
Which options are selected
Information about all debugged processes, that is, all processes that have been or are executing code in interpreted modules
The Auto Attach boxes, Stack Trace label,
Back Trace Size label, and Strings box display
some options set. For details about these options, see section
The process identifier.
The first call to an interpreted function by this
process. (
The registered name, if any. If a registered name is not displayed, it can be that Debugger received information about the process before the name was registered. Try selecting Edit > Refresh.
The current status, one of the following:
The interpreted function call has returned a value, and the process is no longer executing interpreted code.
The process is running.
The process is waiting in a
The process is stopped at a breakpoint.
The process has terminated.
There is no connection to the node where the process is located.
More information, if any. If the process is
stopped at a breakpoint, the field contains information
about the location
Tries to load and restore Debugger settings from a file previously saved using Save Settings... (see below). Any errors are silently ignored.
Notice that settings saved by Erlang/OTP R16B01 or later cannot be read by Erlang/OTP R16B or earlier.
Saves Debugger settings to a file. The settings include the set of interpreted files, breakpoints, and the selected options. The settings can be restored in a later Debugger session using Load Settings... (see above). Any errors are silently ignored.
Stops Debugger.
Updates information about debugged processes. Information about all terminated processes are removed from the window. All Attach Process windows for terminated processes are closed.
Terminates all processes listed in the window using
Opens the
Stops interpreting all modules. Processes executing in interpreted modules terminate.
For each interpreted module, a corresponding entry is added to the Module menu, with the following submenu:
Stops interpreting the selected module. Processes executing in this module terminate.
Opens a
The following menu items apply to the currently selected
process, provided it is stopped at a breakpoint (for details, see
section
The following menu items apply to the currently selected process:
Attaches to the process and open an
Terminates the process using
The items in this menu are used to create and delete breakpoints.
For details, see section
Sets a line breakpoint.
Sets a conditional breakpoint.
Sets a function breakpoint.
Enables all breakpoints.
Disables all breakpoints.
Removes all breakpoints.
For each breakpoint, a corresponding entry is added to the Break menu, from which it is possible to disable, enable, or delete the breakpoint, and to change its trigger action.
Sets the areas to be visible in an
Sets the events a debugged process is to be attached to automatically. Affects existing debugged processes.
First Call - The first time a process calls a function in an interpreted module.
On Exit - At process termination.
On Break - When a process reaches a breakpoint.
Sets the stack trace option, see section
Stack On, Tail - Saves information about all current calls.
Stack On, No Tail - Saves information about current calls, discarding previous information when a tail recursive call is made.
Stack Off - Does not save any information about current calls.
Sets the integer lists to be printed as strings. Does not affect existing debugged processes.
Use range of +pc flag - Uses the printable
character range set by the
Sets how many call frames to be fetched when inspecting the call stack from the Attach Process window. Does not affect existing Attach Process windows.
Contains a menu item for each open Debugger window. Selecting one of the items raises the corresponding window.
Shows the Debugger documentation. This function requires a web browser.
The Interpret Modules window is used for selecting which modules
to interpret. Initially, the window displays the modules (
Interpretable modules are modules for which a
Modules for which these requirements are not fulfilled are not interpretable and are therefore displayed within parentheses.
Option
An example of how to compile code with debug information using
% erlc +debug_info module.erl
An example of how to compile code with debug information from the Erlang shell:
4> c(module, debug_info).
To browse the file hierarchy and interpret the appropriate modules,
either select a module name and click Choose (or
press carriage return), or double-click the module name.
Interpreted modules have the type
To interpret all displayed modules in the chosen directory, click All.
To close the window, click Done.
When Debugger is started in global mode (which is the default, see
From an Attach Process window, you can interact with a debugged process. One window is opened for each process that has been attached to. Notice that when attaching to a process, its execution is automatically stopped.
The window is divided into the following five parts:
The Code area, displaying the code being executed. The code
is indented and each line is prefixed with its line number.
If the process execution is stopped, the current line is
marked with
Active breakpoints are displayed in red and inactive breakpoints in blue.
The Button area, with buttons for quick access to frequently used functions in the Process menu.
The Evaluator area, where you can evaluate functions within the context of the debugged process, if that process execution is stopped.
The Bindings area, displaying all variables bindings. If you click a variable name, the value is displayed in the Evaluator area. Double-click a variable name to open a window where the variable value can be edited. Notice however that pid, port, reference, or fun values cannot be edited unless they can be represented in the running system.
The Trace area, which displays a trace output for the process.
Function call, where
Function return value
.The message
The message
Waiting in a
Waiting in a
The Trace area also displays Back Trace, a summary of the current function calls on the stack.
Using the Options menu, you can set which areas to be displayed. By default, all areas except the Trace area are displayed.
Closes this window and detach from the process.
Goes to a specified line number.
Searches for a specified string.
Executes the current code line, stepping into any (interpreted) function calls.
Executes the current code line and stop at the next line.
Continues the execution.
Continues the execution until the current function returns.
Skips the current code line and stop at the next
line. If used on the last line in a function body,
the function returns
Simulates a time-out when executing a
Stops the execution of a running process, that is, make the process stop at a breakpoint. The command takes effect (visibly) the next time the process receives a message.
Verifies that the current location of the execution is visible in the code area.
Terminates the process using
Inspects the message queue of the process. The queue is displayed in the Evaluator area.
Displays the back trace of the process, a summary of the current function calls on the stack, in the Trace area. Requires that the Trace area is visible and that the Stack Trace option is Stack On, Tail or Stack On, No Tail.
Inspects the previous function call on the stack, showing the location and variable bindings.
Inspects the next function call on the stack, showing the location and variable bindings.
Sets which areas are to be visible. Does not affect other Attach Process windows.
Same as in the
Same as in the
Sets how many call frames are to be fetched when inspecting the call stack. Does not affect other Attach Process windows.
The Break, Windows, and Help menus
are the same as in the
The View Module window displays the contents of an interpreted module and makes it possible to set breakpoints.
The source code is indented and each line is prefixed with its line number.
Clicking a line highlights it and selects it to be the target of the breakpoint functions available from the Break menu. To set a line breakpoint on a line, double-click it. To remove the breakpoint, double-click the line with an existing breakpoint.
Breakpoints are marked with a stop symbol.
The File and Edit menus are the same as in the
The Break, Windows, and Help menus
are the same as in the
Execution of interpreted code is naturally slower than for regularly compiled modules. Using Debugger also increases the number of processes in the system, as for each debugged process another process (the meta process) is created.
It is also worth to keep in mind that programs with timers can behave differently when debugged. This is especially true when stopping the execution of a process (for example, at a breakpoint). Time-outs can then occur in other processes that continue execution as normal.
Code loading works almost as usual, except that interpreted modules are also stored in a database and debugged processes use only this stored code. Reinterpreting an interpreted module results in the new version being stored as well, but does not affect existing processes executing an older version of the code. This means that the code replacement mechanism of Erlang does not work for debugged processes.
By using
debugger:start(local | global)
If no argument is provided, Debugger starts in global mode.
In local mode, code is interpreted only at the current node. In global mode, code is interpreted at all known nodes. Processes at other nodes executing interpreted code are automatically displayed in the Monitor window and can be attached to like any other debugged process.
It is possible, but definitely not recommended, to start Debugger in global mode on more than one node in a network, as the nodes interfere with each other, leading to inconsistent behavior.