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.

Breakpoints are created and deleted using the Break menu of the Monitor window, View Module window and Attach Process window.

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 line breakpoint is created at a certain line in a module.

The Line Break Dialog Window.

Right-clicking the Module entry will 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 or Attach Process window.

A conditional breakpoint is created at a certain line in the module, but a process reaching the breakpoint will stop only if a given condition is true.

The condition is specified by the user as a module name CModule and a function name CFunction. When a process reaches the breakpoint, CModule:CFunction(Bindings) will be evaluated. If and only if this function call returns true, the process will stop. If the function call returns false, the breakpoint will be silently ignored.

Bindings is a list of variable bindings. Use the function int:get_binding(Variable,Bindings) to retrieve the value of Variable (given as an atom). The function returns unbound or {value,Value}.

The Conditional Break Dialog Window.

Right-clicking the Module entry will open a popup menu from which the appropriate module can be selected.

Example: A conditional breakpoint calling c_test:c_break/1 is added at line 8 in the module fac. Each time the breakpoint is reached, the function is called, and when N is equal to 3 it returns true, and the process stops.

Extract from fac.erl:

4.   fac(0) ->
5.      1;
6.
7.   fac(N) ->
8.      N * fac(N - 1).

Definition of c_test:c_break/1:

-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 given function.

The Function Break Dialog Window.

Right-clicking the Module entry will open a popup menu from which the appropriate module can be selected.

Clicking the Ok button (or 'Return' or 'Tab') when a module name has been given, will bring up all functions of the module in the listbox.

The Erlang emulator keeps track of a stack trace, information about recent function calls. This information is used, for example, if an error occurs:

1> catch a+1.
{'EXIT',{badarith,[{erlang,'+',[a,1],[]},
                   {erl_eval,do_apply,5,[{file,"erl_eval.erl"},{line,562}]},
                   {erl_eval,expr,5,[{file,"erl_eval.erl"},{line,359}]},
                   {shell,exprs,7,[{file,"shell.erl"},{line,668}]},
                   {shell,eval_exprs,7,[{file,"shell.erl"},{line,623}]},
                   {shell,eval_loop,3,[{file,"shell.erl"},{line,608}]}]}}

See the Erlang Reference Manual, Errors and Error handling, for more information about the stack trace.

The 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 the 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 of the Attach Process window.

By default, the Debugger saves information about all current function calls, that is, function calls that have not yet returned a value (option 'Stack On, Tail').

This means, however, that information is saved also for tail recursive calls. For example, repeated calls to the loop function of an Erlang process. This may consume unnecessary amounts of memory for debugged processes with long lifetimes and many tail recursive calls. It is therefore possible to set the option 'Stack On, no tail', in which case information about previous calls are discarded when a tail recursive call is made.

It is also possible to turn off the Debugger stack trace facility ('Stack Off'). Note: If an error occurs, in this case the stack trace will be empty.

See the section about the Monitor Window for information about how to change the stack trace option.

The Monitor window is the main window of Debugger and shows a listbox containing the names of all interpreted modules (double-clicking a module brings up the View Module window), which options are selected, and information about all debugged processes, that is all processes which have been/are executing code in interpreted modules.

The Auto Attach buttons, Stack Trace label and Back Trace Size label show some options set, see Options Menu for further information about these options.

The interpret dialog module is used for selecting which modules to interpret. Initially, the window shows the modules (erl files) and subdirectories of the current working directory.

Interpretable modules are modules for which a BEAM file, compiled with the option debug_info set, can be found in the same directory as the source code, or in an ebin directory next to it.

Modules, for which the above requirements are not fulfilled, are not interpretable and are therefore displayed within parentheses.

The debug_info option causes debug information or abstract code to be added to the BEAM file. This will increase the size of the file, and also makes it possible to reconstruct the source code. It is therefore recommended not to include debug information in code aimed for target systems.

An example of how to compile code with debug information using erlc:
% erlc +debug_info module.erl

An example of how to compile code with debug information from the Erlang shell:
4> c(module, debug_info).

Browse the file hierarchy and interpret the appropriate modules by selecting a module name and pressing Choose (or carriage return), or by double clicking the module name. Interpreted modules are displayed with a * in front of the name.

Pressing All will interpret all displayed modules in the chosen directory.

Pressing Done will close the window.

From an Attach Process window the user can interact with a debugged process. One window is opened for each process that has been attached to. Note that when attaching to a process, its execution is automatically stopped.

The window is divided into five parts:

It is configurable using the Options menu which areas should be shown or hidden. By default, all areas except the Trace area is shown.

The View Module window shows 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 will highlight it and select it to be the target of the breakpoint functions available from the Break menu. Doubleclicking a line will set a line breakpoint on that line. Doubleclicking a line with an existing breakpoint will remove the breakpoint.

Breakpoints are marked with -@-.