<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html xmlns:fn="http://www.w3.org/2005/02/xpath-functions">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<link rel="stylesheet" href="../../../../doc/otp_doc.css" type="text/css">
<title>Erlang -- Debugger</title>
</head>
<body bgcolor="white" text="#000000" link="#0000ff" vlink="#ff00ff" alink="#ff0000"><div id="container">
<script id="js" type="text/javascript" language="JavaScript" src="../../../../doc/js/flipmenu/flipmenu.js"></script><script id="js2" type="text/javascript" src="../../../../doc/js/erlresolvelinks.js"></script><script language="JavaScript" type="text/javascript">
<!--
function getWinHeight() {
var myHeight = 0;
if( typeof( window.innerHeight ) == 'number' ) {
//Non-IE
myHeight = window.innerHeight;
} else if( document.documentElement && ( document.documentElement.clientWidth ||
document.documentElement.clientHeight ) ) {
//IE 6+ in 'standards compliant mode'
myHeight = document.documentElement.clientHeight;
} else if( document.body && ( document.body.clientWidth || document.body.clientHeight ) ) {
//IE 4 compatible
myHeight = document.body.clientHeight;
}
return myHeight;
}
function setscrollpos() {
var objf=document.getElementById('loadscrollpos');
document.getElementById("leftnav").scrollTop = objf.offsetTop - getWinHeight()/2;
}
function addEvent(obj, evType, fn){
if (obj.addEventListener){
obj.addEventListener(evType, fn, true);
return true;
} else if (obj.attachEvent){
var r = obj.attachEvent("on"+evType, fn);
return r;
} else {
return false;
}
}
addEvent(window, 'load', setscrollpos);
//--></script><div id="leftnav"><div class="innertube">
<img alt="Erlang logo" src="../../../../doc/erlang-logo.png"><br><small><a href="users_guide.html">User's Guide</a><br><a href="index.html">Reference Manual</a><br><a href="release_notes.html">Release Notes</a><br><a href="../pdf/debugger-3.2.8.pdf">PDF</a><br><a href="../../../../doc/index.html">Top</a></small><p><strong>Debugger</strong><br><strong>User's Guide</strong><br><small>Version 3.2.8</small></p>
<br><a href="javascript:openAllFlips()">Expand All</a><br><a href="javascript:closeAllFlips()">Contract All</a><p><small><strong>Chapters</strong></small></p>
<ul class="flipMenu" imagepath="../../../../doc/js/flipmenu"><li id="loadscrollpos" title="Debugger" expanded="true">Debugger<ul>
<li><a href="debugger_chapter.html">
Top of chapter
</a></li>
<li title="Introduction"><a href="debugger_chapter.html#id57237">Introduction</a></li>
<li title="Getting Started with Debugger"><a href="debugger_chapter.html#id61142">Getting Started with Debugger</a></li>
<li title="Breakpoints and Break Dialogue Windows"><a href="debugger_chapter.html#id63134">Breakpoints and Break Dialogue Windows</a></li>
<li title="Stack Trace"><a href="debugger_chapter.html#id58302">Stack Trace</a></li>
<li title="The Monitor Window"><a href="debugger_chapter.html#id62504">The Monitor Window</a></li>
<li title="The Interpret Dialog Window"><a href="debugger_chapter.html#id60722">The Interpret Dialog Window</a></li>
<li title="The Attach Process Window"><a href="debugger_chapter.html#id60849">The Attach Process Window</a></li>
<li title="The View Module Window"><a href="debugger_chapter.html#id59668">The View Module Window</a></li>
<li title="Performance"><a href="debugger_chapter.html#id59744">Performance</a></li>
<li title="Code Loading Mechanism"><a href="debugger_chapter.html#id59763">Code Loading Mechanism</a></li>
<li title="Debugging Remote Nodes"><a href="debugger_chapter.html#id59778">Debugging Remote Nodes</a></li>
</ul>
</li></ul>
</div></div>
<div id="content">
<div class="innertube">
<h1>1 Debugger</h1>
<h3><a name="id57237">1.1
Introduction</a></h3>
<p><strong>Debugger</strong> is a graphical user interface for the Erlang
interpreter, which can be used for debugging and testing of
Erlang programs. For example, breakpoints can be set, code can be
single stepped and variable values can be displayed and changed.
</p>
<p>The Erlang interpreter can also be accessed via the interface
module <span class="code">int</span>, see <span class="bold_code"><a href="int.html">int(3)</a></span>.
</p>
<p><strong>Warning:</strong> Note that the Debugger at some point might
start tracing on the processes which execute the interpreted
code. This means that a conflict will occur if tracing by other
means is started on any of these processes.</p>
<h3><a name="id61142">1.2
Getting Started with Debugger</a></h3>
<p>Start Debugger by calling <span class="code">debugger:start()</span>. It will start
the <span class="bold_code"><a href="#monitor">Monitor window</a></span> showing
information about all debugged processes, interpreted modules and
selected options.</p>
<p>Initially there are normally no debugged processes. First, it
must be specified which modules should be <strong>debugged</strong>, or
<strong>interpreted</strong> as it is also called. This is done by
choosing <strong>Module->Interpret...</strong> in the Monitor window and
then selecting the appropriate modules from the
<span class="bold_code"><a href="#interpret">Interpret Dialog window</a></span>.
</p>
<div class="note">
<div class="label">Note</div>
<div class="content"><p>
<p>Only modules compiled with the option <span class="code">debug_info</span> set
can be interpreted. Non-interpretable modules are shown within
parenthesis in the Interpret Dialog window.</p>
</p></div>
</div>
<p>When a module is interpreted, it can be viewed in a
<span class="bold_code"><a href="#view">View Module window</a></span>. This is done
by selecting the module from the <strong>Module->module->View</strong>
menu. The contents of the source file is shown and it is possible
to set <span class="bold_code"><a href="#breakpoints">breakpoints</a></span>.</p>
<p>Now the program that should be debugged can be started. This is
done the normal way from the Erlang shell. All processes executing
code in interpreted modules will be displayed in the Monitor
window. It is possible to <strong>attach</strong> to one of these
processes, by double-clicking it, or by selecting the process and
then choosing <strong>Process->Attach</strong>.</p>
<p>Attaching to a process will result in a
<span class="bold_code"><a href="#attach">Attach Process window</a></span> being
opened for this process. From the Attach Process window, it is
possible to control the process execution, inspect variable
values, set breakpoints etc.</p>
<h3><a name="id63134">1.3
Breakpoints and Break Dialogue Windows</a></h3>
<a name="breakpoints"></a>
<p>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.</p>
<div class="note">
<div class="label">Note</div>
<div class="content"><p>
<p>When a process reaches a breakpoint, only that process is
stopped. Other processes are not affected.</p>
</p></div>
</div>
<p>Breakpoints are created and deleted using the Break menu of
the Monitor window, View Module window and Attach Process window.
</p>
<h4>Executable Lines</h4>
<p>To have effect, a breakpoint must be set at an
<strong>executable line</strong>, 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 <span class="code">case</span>- or <span class="code">receive</span> statement is not
executable.</p>
<p>In the example below, lines number 2, 4, 6, 8 and 11 are
executable lines:</p>
<div class="example"><pre>
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.</pre></div>
<h4>Status and Trigger Action</h4>
<p>A breakpoint can be either <strong>active</strong> or
<strong>inactive</strong>. Inactive breakpoints are ignored.</p>
<p>Each breakpoint has a <strong>trigger action</strong> which specifies
what should happen when a process has reached it (and stopped):
</p>
<ul>
<li>
<strong>enable</strong> Breakpoint should remain active (default).
</li>
<li>
<strong>disable</strong> Breakpoint should be made inactive.
</li>
<li>
<strong>delete</strong> Breakpoint should be deleted.</li>
</ul>
<h4>Line Breakpoints</h4>
<p>A line breakpoint is created at a certain line in a module.</p>
<img alt="IMAGE MISSING" src="images/line_break_dialog.gif"><br>
<em>Figure
1.1:
The Line Break Dialog Window.</em>
<p>Right-clicking the Module entry will open a popup menu from
which the appropriate module can be selected.</p>
<p>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.</p>
<h4>Conditional Breakpoints</h4>
<p>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.</p>
<p>The condition is specified by the user as a module name
<span class="code">CModule</span> and a function name <span class="code">CFunction</span>. When a
process reaches the breakpoint,
<span class="code">CModule:CFunction(Bindings)</span> will be evaluated. If and
only if this function call returns <span class="code">true</span>, the process
will stop. If the function call returns <span class="code">false</span>,
the breakpoint will be silently ignored.</p>
<p><span class="code">Bindings</span> is a list of variable bindings. Use
the function <span class="code">int:get_binding(Variable,Bindings)</span> to
retrieve the value of <span class="code">Variable</span> (given as an atom).
The function returns <span class="code">unbound</span> or <span class="code">{value,Value}</span>.</p>
<img alt="IMAGE MISSING" src="images/cond_break_dialog.gif"><br>
<em>Figure
1.2:
The Conditional Break Dialog Window.</em>
<p>Right-clicking the Module entry will open a popup menu from
which the appropriate module can be selected.</p>
<p>Example: A conditional breakpoint calling
<span class="code">c_test:c_break/1</span> is added at line 8 in the module
<span class="code">fac</span>. Each time the breakpoint is reached, the function is
called, and when <span class="code">N</span> is equal to 3 it returns <span class="code">true</span>,
and the process stops.</p>
<p>Extract from <span class="code">fac.erl</span>:</p>
<div class="example"><pre>
4. fac(0) ->
5. 1;
6.
7. fac(N) ->
8. N * fac(N - 1).</pre></div>
<p>Definition of <span class="code">c_test:c_break/1</span>:</p>
<div class="example"><pre>
-module(c_test).
-export([c_break/1]).
c_break(Bindings) ->
case int:get_binding('N', Bindings) of
{value, 3} ->
true;
_ ->
false
end.</pre></div>
<h4>Function Breakpoints</h4>
<p>A function breakpoint is a set of line breakpoints, one at
the first line of each clause in the given function.</p>
<img alt="IMAGE MISSING" src="images/function_break_dialog.gif"><br>
<em>Figure
1.3:
The Function Break Dialog Window.</em>
<p>Right-clicking the Module entry will open a popup menu from
which the appropriate module can be selected.</p>
<p>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.</p>
<h3><a name="id58302">1.4
Stack Trace</a></h3>
<a name="stack_trace"></a>
<p>The Erlang emulator keeps track of a <strong>stack trace</strong>,
information about recent function calls. This information is
used, for example, if an error occurs:</p>
<div class="example"><pre>
1> <span class="bold_code">catch a+1.</span>
{'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}]}]}}</pre></div>
<p>See the <strong>Erlang Reference Manual, Errors and Error handling</strong>,
for more information about the stack trace.</p>
<p>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).</p>
<p>This information can be used to traverse the chain of function
calls, using the 'Up' and 'Down' buttons of
<span class="bold_code"><a href="#attach">the Attach Process window</a></span>.
</p>
<p>By default, the Debugger only saves information about recursive
function calls, that is, function calls that have not yet returned
a value (option 'Stack On, No Tail').</p>
<p>Sometimes, however, it can be useful to save all calls, even
tail-recursive calls. That can be done with the 'Stack On, Tail'
option. Note that this option will consume more memory and slow
down execution of interpreted functions when there are many
tail-recursive calls.
</p>
<p>It is also possible to turn off the Debugger stack trace
facility ('Stack Off'). <strong>Note:</strong> If an error occurs, in this
case the stack trace will be empty.</p>
<p>See the section about <span class="bold_code"><a href="#monitor">the Monitor
Window</a></span> for information about how to change the stack
trace option.</p>
<h3><a name="id62504">1.5
The Monitor Window</a></h3>
<a name="monitor"></a>
<p>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.</p>
<img alt="IMAGE MISSING" src="images/monitor.gif"><br>
<em>Figure
1.4:
The Monitor Window.</em>
<p>The Auto Attach buttons, Stack Trace label and Back Trace Size
label show some options set, see
<span class="bold_code"><a href="#options">Options Menu</a></span> for further
information about these options.</p>
<h4>Process Grid</h4>
<dl>
<dt><strong><strong>Pid</strong></strong></dt>
<dd><p>The process identifier.</p></dd>
<dt><strong><strong>Initial Call</strong></strong></dt>
<dd><p>The first call to an interpreted function by this
process. (<span class="code">Module:Function/Arity</span>)</p></dd>
<dt><strong><strong>Name</strong></strong></dt>
<dd><p>The registered name, if any. If a registered name does
not show up, it may be that the Debugger received
information about the process before the name had been
registered. Try selecting <strong>Edit->Refresh</strong>.</p></dd>
<dt><strong><strong>Status</strong></strong></dt>
<dd>
<p>The current status, one of the following:</p>
<dl>
<dt><strong><strong>idle</strong></strong></dt>
<dd><p>The interpreted function call has returned a value,
and the process is no longer executing interpreted code.
</p></dd>
<dt><strong><strong>running</strong></strong></dt>
<dd><p>The process is running.</p></dd>
<dt><strong><strong>waiting</strong></strong></dt>
<dd><p>The process is waiting in a <span class="code">receive</span>
statement.</p></dd>
<dt><strong><strong>break</strong></strong></dt>
<dd><p>The process is stopped at a breakpoint.</p></dd>
<dt><strong><strong>exit</strong></strong></dt>
<dd><p>The process has terminated.</p></dd>
<dt><strong><strong>no_conn</strong></strong></dt>
<dd><p>There is no connection to the node where
the process is located.</p></dd>
</dl>
</dd>
<dt><strong><strong>Information</strong></strong></dt>
<dd><p>Additional information, if any. If the process is
stopped at a breakpoint, the field contains information
about the location <span class="code">{Module,Line}</span>. If the process has
terminated, the field contains the exit reason.</p></dd>
</dl>
<h4>The File Menu</h4>
<dl>
<dt><strong><strong>Load Settings...</strong></strong></dt>
<dd>
<p>Try to load and restore Debugger settings from a file
previously saved using <strong>Save Settings...</strong>, see below.
Any errors are silently ignored.</p>
</dd>
<dt><strong><strong>Save Settings...</strong></strong></dt>
<dd>
<p>Save 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 <strong>Load Settings...</strong>, see above.
Any errors are silently ignored.</p>
</dd>
<dt><strong><strong>Exit</strong></strong></dt>
<dd><p>Stop Debugger.</p></dd>
</dl>
<h4>The Edit Menu</h4>
<dl>
<dt><strong><strong>Refresh</strong></strong></dt>
<dd><p>Update information about debugged processes. Removes
information about all terminated processes from the window,
and also closes all Attach Process windows for terminated
processes.</p></dd>
<dt><strong><strong>Kill All</strong></strong></dt>
<dd><p>Terminate all processes listed in the window using
<span class="code">exit(Pid,kill)</span>.</p></dd>
</dl>
<h4>The Module Menu</h4>
<dl>
<dt><strong><strong>Interpret...</strong></strong></dt>
<dd><p>Open the <span class="bold_code"><a href="#interpret">Interpret Dialog
window</a></span> where new modules to be interpreted can
be specified.</p></dd>
<dt><strong><strong>Delete All</strong></strong></dt>
<dd><p>Stop interpreting all modules. Processes executing in
interpreted modules will terminate.</p></dd>
</dl>
<p>For each interpreted module, a corresponding entry is added to
the Module menu, with the following submenu:</p>
<dl>
<dt><strong><strong>Delete</strong></strong></dt>
<dd><p>Stop interpreting the selected module. Processes
executing in this module will terminate.</p></dd>
<dt><strong><strong>View</strong></strong></dt>
<dd><p>Open a <span class="bold_code"><a href="#view">View Module
window</a></span> showing the contents of the selected
module.</p></dd>
</dl>
<h4>The Process Menu</h4>
<p>The following menu items apply to the currently selected
process, provided it is stopped at a breakpoint. See the chapter
about the <span class="bold_code"><a href="#attach">Attach Process
window</a></span> for more information.</p>
<dl>
<dt><strong><strong>Step</strong></strong></dt>
<dd></dd>
<dt><strong><strong>Next</strong></strong></dt>
<dd></dd>
<dt><strong><strong>Continue</strong></strong></dt>
<dd></dd>
<dt><strong><strong>Finish</strong></strong></dt>
<dd></dd>
</dl>
<p>The following menu items apply to the currently selected
process.</p>
<dl>
<dt><strong><strong>Attach</strong></strong></dt>
<dd><p>Attach to the process and open a
<span class="bold_code"><a href="#attach">Attach Process window</a></span>.
</p></dd>
<dt><strong><strong>Kill</strong></strong></dt>
<dd>
<p>Terminate the process using <span class="code">exit(Pid,kill)</span>.</p>
</dd>
</dl>
<h4>The Break Menu</h4>
<p>The items in this menu are used to create and delete
breakpoints.
See the <span class="bold_code"><a href="#breakpoints">Breakpoints</a></span>
chapter for more information.</p>
<dl>
<dt><strong><strong>Line Break...</strong></strong></dt>
<dd><p>Set a line breakpoint.</p></dd>
<dt><strong><strong>Conditional Break...</strong></strong></dt>
<dd><p>Set a conditional breakpoint.</p></dd>
<dt><strong><strong>Function Break...</strong></strong></dt>
<dd><p>Set a function breakpoint.</p></dd>
<dt><strong><strong>Enable All</strong></strong></dt>
<dd><p>Enable all breakpoints.</p></dd>
<dt><strong><strong>Disable All</strong></strong></dt>
<dd><p>Disable all breakpoints.</p></dd>
<dt><strong><strong>Delete All</strong></strong></dt>
<dd><p>Remove all breakpoints.</p></dd>
</dl>
<p>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.</p>
<h4>The Options Menu</h4>
<a name="options"></a>
<dl>
<dt><strong><strong>Trace Window</strong></strong></dt>
<dd>
<p>Set which areas should be visible in
an <span class="bold_code"><a href="#attach">Attach Process
window</a></span>. Does not affect already existing
Attach Process windows.</p>
</dd>
<dt><strong><strong>Auto Attach</strong></strong></dt>
<dd>
<p>Set at which events a debugged process should be
automatically attached to. Affects existing debugged
processes.</p>
<ul>
<li>
<strong>First Call</strong> - the first time a process calls a
function in an interpreted module.</li>
<li>
<strong>On Exit</strong> - at process termination.</li>
<li>
<strong>On Break</strong> - when a process reaches a
breakpoint.</li>
</ul>
</dd>
<dt><strong><strong>Stack Trace</strong></strong></dt>
<dd>
<p>Set stack trace option, see section
<span class="bold_code"><a href="#stack_trace">Stack Trace</a></span>. Does not
affect already existing debugged processes.</p>
<ul>
<li>
<strong>Stack On, Tail</strong> - save information about all
current calls.</li>
<li>
<strong>Stack On, No Tail</strong> - save information about
current calls, discarding previous information when a tail
recursive call is made.</li>
<li>
<strong>Stack Off</strong> - do not save any information about
current calls.</li>
</ul>
</dd>
<dt><strong><strong>Back Trace Size...</strong></strong></dt>
<dd>
<p>Set how many call frames should be fetched when
inspecting the call stack from the Attach Process window.
Does not affect already existing Attach Process windows.</p>
</dd>
</dl>
<h4>The Windows Menu</h4>
<p>Contains a menu item for each open Debugger window. Selecting
one of the items will raise the corresponding window.</p>
<h4>The Help Menu</h4>
<dl>
<dt><strong><strong>Help</strong></strong></dt>
<dd><p>View the Debugger documentation. Currently this
function requires Netscape to be up and running.</p></dd>
</dl>
<h3><a name="id60722">1.6
The Interpret Dialog Window</a></h3>
<a name="interpret"></a>
<p>The interpret dialog module is used for selecting which modules
to interpret. Initially, the window shows the modules (<span class="code">erl</span>
files) and subdirectories of the current working directory.</p>
<p>Interpretable modules are modules for which a BEAM file, compiled
with the option <span class="code">debug_info</span> set, can be found in the same
directory as the source code, or in an <span class="code">ebin</span> directory next
to it.</p>
<p>Modules, for which the above requirements are not fulfilled, are
not interpretable and are therefore displayed within parentheses.
</p>
<p>The <span class="code">debug_info</span> option causes <strong>debug information</strong> or
<strong>abstract code</strong> 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.</p>
<p>An example of how to compile code with debug information using
<span class="code">erlc</span>:<br>
<span class="code">% erlc +debug_info module.erl</span></p>
<p>An example of how to compile code with debug information from
the Erlang shell:<br>
<span class="code">4> c(module, debug_info).</span></p>
<img alt="IMAGE MISSING" src="images/interpret.gif"><br>
<em>Figure
1.5:
The Interpret Dialog Window.</em>
<p>Browse the file hierarchy and interpret the appropriate modules
by selecting a module name and pressing <strong>Choose</strong> (or
carriage return), or by double clicking the module name.
Interpreted modules are displayed with a * in front of the name.
</p>
<p>Pressing <strong>All</strong> will interpret all displayed modules in
the chosen directory.</p>
<p>Pressing <strong>Done</strong> will close the window.</p>
<div class="note">
<div class="label">Note</div>
<div class="content"><p>
<p>When the Debugger is started in global mode (which is
the default, see
<span class="bold_code"><a href="javascript:erlhref('../../../../doc/../','debugger','debugger.html#start-0');">debugger:start/0</a></span>),
modules added (or deleted) for interpretation will be added (or
deleted) on all known Erlang nodes.</p>
</p></div>
</div>
<h3><a name="id60849">1.7
The Attach Process Window</a></h3>
<a name="attach"></a>
<p>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.
</p>
<img alt="IMAGE MISSING" src="images/attach.gif"><br>
<em>Figure
1.6:
The Attach Process Window.</em>
<p>The window is divided into five parts:</p>
<ul>
<li>
<p>The Code area, showing 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 <strong>--></strong>. An existing break point at a line
is marked with <strong>-@-</strong>. In the example above,
the execution has been stopped at line 56, before
the execution of <span class="code">io:format/2</span>.</p>
<p>Active breakpoints are shown in red, while inactive
breakpoints are shown in blue.</p>
</li>
<li>The Button area, with buttons for quick access to frequently
used functions in the Process menu.</li>
<li>The Evaluator area, where the user can evaluate functions
within the context of the debugged process, provided that
process execution has been stopped.</li>
<li>The Bindings area, showing all variables bindings.
Clicking on a variable name will result in the value being
displayed in the Evaluator area.
Double-clicking on a variable name will open a window where
the variable value may be edited. Note however that pid,
reference, binary or port values can not be edited.
</li>
<li>
<p>The Trace area, showing a trace output for the process.
</p>
<dl>
<dt><strong><span class="code">++ (N) <L></span></strong></dt>
<dd>Function call, where <span class="code">N</span> is the call level and
<span class="code">L</span> the line number.</dd>
<dt><strong><span class="code">-- (N)</span></strong></dt>
<dd>Function return value.</dd>
<dt><strong><span class="code">==> Pid : Msg</span></strong></dt>
<dd>The message <span class="code">Msg</span> is sent to process <span class="code">Pid</span>.
</dd>
<dt><strong><span class="code"><== Msg</span></strong></dt>
<dd>The message <span class="code">Msg</span> is received.</dd>
<dt><strong><span class="code">++ (N) receive</span></strong></dt>
<dd>Waiting in a <span class="code">receive</span>.</dd>
<dt><strong><span class="code">++ (N) receive with timeout</span></strong></dt>
<dd>Waiting in a <span class="code">receive...after</span>.</dd>
</dl>
<p>Also the back trace, a summary of the current function calls
on the stack, is displayed in the Trace area.</p>
</li>
</ul>
<p>It is configurable using the Options menu which areas should
be shown or hidden. By default, all areas except the Trace area
is shown.</p>
<h4>The File Menu</h4>
<dl>
<dt><strong><strong>Close</strong></strong></dt>
<dd>
<p>Close this window and detach from the process.</p>
</dd>
</dl>
<h4>The Edit Menu</h4>
<dl>
<dt><strong><strong>Go to line...</strong></strong></dt>
<dd><p>Go to a specified line number.</p></dd>
<dt><strong><strong>Search...</strong></strong></dt>
<dd><p>Search for a specified string.</p></dd>
</dl>
<h4>The Process Menu</h4>
<dl>
<dt><strong><strong>Step</strong></strong></dt>
<dd><p>Execute the current line of code, stepping into any
(interpreted) function calls.</p></dd>
<dt><strong><strong>Next</strong></strong></dt>
<dd><p>Execute the current line of code and stop at the next
line.</p></dd>
<dt><strong><strong>Continue</strong></strong></dt>
<dd><p>Continue the execution.</p></dd>
<dt><strong><strong>Finish</strong></strong></dt>
<dd><p>Continue the execution until the current function
returns.</p></dd>
<dt><strong><strong>Skip</strong></strong></dt>
<dd><p>Skip the current line of code and stop at the next
line. If used on the last line in a function body,
the function will return <span class="code">skipped</span>.</p></dd>
<dt><strong><strong>Time Out</strong></strong></dt>
<dd><p>Simulate a timeout when executing a
<span class="code">receive...after</span> statement.</p></dd>
<dt><strong><strong>Stop</strong></strong></dt>
<dd><p>Stop the execution of a running process, that is, make
the process stop as at a breakpoint. The command will take
effect (visibly) the next time the process receives a
message.</p></dd>
<dt><strong><strong>Where</strong></strong></dt>
<dd><p>Make sure the current location of the execution is
visible in the code area.</p></dd>
<dt><strong><strong>Kill</strong></strong></dt>
<dd>
<p>Terminate the process using <span class="code">exit(Pid,kill)</span>.</p>
</dd>
<dt><strong><strong>Messages</strong></strong></dt>
<dd><p>Inspect the message queue of the process. The queue is
printed in the evaluator area.</p></dd>
<dt><strong><strong>Back Trace</strong></strong></dt>
<dd>
<p>Display 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'.</p>
</dd>
<dt><strong><strong>Up</strong></strong></dt>
<dd><p>Inspect the previous function call on the stack,
showing the location and variable bindings.</p></dd>
<dt><strong><strong>Down</strong></strong></dt>
<dd><p>Inspect the next function call on the stack, showing
the location and variable bindings.</p></dd>
</dl>
<h4>The Options Menu</h4>
<dl>
<dt><strong><strong>Trace Window</strong></strong></dt>
<dd>
<p>Set which areas should be visible. Does not affect
other Attach Process windows.</p>
</dd>
<dt><strong><strong>Stack Trace</strong></strong></dt>
<dd>
<p>Same as in <span class="bold_code"><a href="#monitor">the Monitor
window</a></span>, but does only affect the debugged
process the window is attached to.</p>
</dd>
<dt><strong><strong>Back Trace Size...</strong></strong></dt>
<dd>
<p>Set how many call frames should be fetched when
inspecting the call stack. Does not affect other Attach
Process windows.</p>
</dd>
</dl>
<h4>Break, Windows and Help Menus</h4>
<p>The Break, Windows and Help menus look the same as in
the Monitor window, see the chapter
<span class="bold_code"><a href="#monitor">The Monitor Window</a></span>, except
that the Breaks menu apply to the local breakpoints only.</p>
<h3><a name="id59668">1.8
The View Module Window</a></h3>
<a name="view"></a>
<p>The View Module window shows the contents of an interpreted
module and makes it possible to set breakpoints.</p>
<img alt="IMAGE MISSING" src="images/view.gif"><br>
<em>Figure
1.7:
The View Module Window.</em>
<p>The source code is indented and each line is prefixed with its
line number.</p>
<p>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.</p>
<p>Breakpoints are marked with <strong>-@-</strong>.</p>
<h4>File and Edit Menus</h4>
<p>The File and Edit menus look the same as in the Attach Process
window, see the chapter <span class="bold_code"><a href="#attach">The Attach
Process Window</a></span>.</p>
<h4>Break, Windows and Help Menus</h4>
<p>The Break, Windows and Help menus look the same as in
the Monitor window, see the chapter
<span class="bold_code"><a href="#monitor">The Monitor Window</a></span>, except
that the Breaks menu apply to the local breakpoints only.</p>
<h3><a name="id59744">1.9
Performance</a></h3>
<p>Execution of interpreted code is naturally slower than for
regularly compiled modules. Using the Debugger also increases
the number of processes in the system, as for each debugged
process another process (the meta process) is created.</p>
<p>It is also worth to keep in mind that programs with timers may
behave differently when debugged. This is especially true when
stopping the execution of a process, for example at a
breakpoint. Timeouts can then occur in other processes that
continue execution as normal.</p>
<h3><a name="id59763">1.10
Code Loading Mechanism</a></h3>
<p>Code loading works almost as usual, except that interpreted
modules are also stored in a database and debugged processes
uses only this stored code. Re-interpreting an interpreted
module will result 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.</p>
<h3><a name="id59778">1.11
Debugging Remote Nodes</a></h3>
<p>By using <span class="code">debugger:start/1</span>, it can be specified if Debugger
should be started in local or global mode.</p>
<div class="example"><pre>
debugger:start(local | global)</pre></div>
<p>If no argument is provided, Debugger is started in global mode.
</p>
<p>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 will automatically be
shown in the Monitor window and can be attached to like any other
debugged process.</p>
<p>It is possible, but definitely not recommended to start Debugger
in global mode on more than one node in a network, as they will
interfere with each other leading to inconsistent behaviour.</p>
</div>
<div class="footer">
<hr>
<p>Copyright © 1997-2012 Ericsson AB. All Rights Reserved.</p>
</div>
</div>
</div></body>
</html>
distrib
>
Fedora
>
17
>
i386
>
media
>
updates
>
by-pkgid
>
675c8c8167236dfcf8d66da674f931e8
>
files
>
489
