1
<?xml version="1.0" encoding="latin1" ?>
2
<!DOCTYPE chapter SYSTEM "chapter.dtd">
9
<holder>Ericsson AB, All Rights Reserved</holder>
12
The contents of this file are subject to the Erlang Public License,
13
Version 1.1, (the "License"); you may not use this file except in
14
compliance with the License. You should have received a copy of the
15
Erlang Public License along with this software. If not, it can be
16
retrieved online at http://www.erlang.org/.
18
Software distributed under the License is distributed on an "AS IS"
19
basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See
20
the License for the specific language governing rights and limitations
23
The Initial Developer of the Original Code is Ericsson AB.
26
<title>Debugger</title>
34
<title>Introduction</title>
36
<p><em>Debugger</em> is a graphical user interface for the Erlang
37
interpreter, which can be used for debugging and testing of
38
Erlang programs. For example, breakpoints can be set, code can be
39
single stepped and variable values can be displayed and changed.
42
<p>The Erlang interpreter can also be accessed via the interface
43
module <c>int</c>, see <seealso marker="int">int(3)</seealso>.
46
<p><em>Warning:</em> Note that the Debugger at some point might
47
start tracing on the processes which execute the interpreted
48
code. This means that a conflict will occur if tracing by other
49
means is started on any of these processes.</p>
53
<title>Getting Started with Debugger</title>
55
<p>Start Debugger by calling <c>debugger:start()</c>. It will start
56
the <seealso marker="#monitor">Monitor window</seealso> showing
57
information about all debugged processes, interpreted modules and
60
<p>Initially there are normally no debugged processes. First, it
61
must be specified which modules should be <em>debugged</em>, or
62
<em>interpreted</em> as it is also called. This is done by
63
chosing <em>Module->Interpret...</em> in the Monitor window and
64
then selecting the appropriate modules from the
65
<seealso marker="#interpret">Interpret Dialog window</seealso>.
69
<p>Only modules compiled with the option <c>debug_info</c> set
70
can be interpreted. Non-interpretable modules are shown within
71
parenthesis in the Interpret Dialog window.</p>
74
<p>When a module is interpreted, it can be viewed in a
75
<seealso marker="#view">View Module window</seealso>. This is done
76
by selecting the module from the <em>Module->module->View</em>
77
menu. The contents of the source file is shown and it is possible
78
to set <seealso marker="#breakpoints">breakpoints</seealso>.</p>
80
<p>Now the program that should be debugged can be started. This is
81
done the normal way from the Erlang shell. All processes executing
82
code in interpreted modules will be displayed in the Monitor
83
window. It is possible to <em>attach</em> to one of these
84
processes, by double-clicking it, or by selecting the process and
85
then chosing <em>Process->Attach</em>.</p>
87
<p>Attaching to a process will result in a
88
<seealso marker="#attach">Attach Process window</seealso> being
89
opened for this process. From the Attach Process window, it is
90
possible to control the process execution, inspect variable
91
values, set breakpoints etc.</p>
95
<marker id="breakpoints"/>
96
<title>Breakpoints and Break Dialogue Windows</title>
98
<p>Once the appropriate modules are interpreted, breakpoints can
99
be set at relevant locations in the source code. Breakpoints are
100
specified on a line basis. When a process reaches a breakpoint,
101
it stops and waits for commands (step, skip, continue,...) from
105
<p>When a process reaches a breakpoint, only that process is
106
stopped. Other processes are not affected.</p>
109
<p>Breakpoints are created and deleted using the Break menu of
110
the Monitor window, View Module window and Attach Process window.
114
<title>Executable Lines</title>
116
<p>To have effect, a breakpoint must be set at an
117
<em>executable line</em>, which is a line of code containing an
118
executable expression such as a matching or a function call.
119
A blank line or a line containing a comment, function head or
120
pattern in a <c>case</c>- or <c>receive</c> statement is not
123
<p>In the example below, lines number 2, 4, 6, 8 and 11 are
124
executable lines:</p>
126
1: is_loaded(Module,Compiled) ->
127
2: case get_file(Module,Compiled) of
129
4: case code:which(Module) of
141
<title>Status and Trigger Action</title>
143
<p>A breakpoint can be either <em>active</em> or
144
<em>inactive</em>. Inactive breakpoints are ignored.</p>
146
<p>Each breakpoint has a <em>trigger action</em> which specifies
147
what should happen when a process has reached it (and stopped):
150
<item><em>enable</em> Breakpoint should remain active (default).
152
<item><em>disable</em> Breakpoint should be made inactive.
154
<item><em>delete</em> Breakpoint should be deleted.</item>
159
<title>Line Breakpoints</title>
161
<p>A line breakpoint is created at a certain line in a module.</p>
163
<image file="images/line_break_dialog">
164
<icaption>The Line Break Dialog Window.</icaption>
167
<p>Right-clicking the Module entry will open a popup menu from
168
which the appropriate module can be selected.</p>
170
<p>A line breakpoint can also be created (and deleted) by
171
double-clicking the line when the module is displayed in
172
the View Module or Attach Process window.</p>
176
<title>Conditional Breakpoints</title>
178
<p>A conditional breakpoint is created at a certain line in
179
the module, but a process reaching the breakpoint will stop
180
only if a given condition is true.</p>
182
<p>The condition is specified by the user as a module name
183
<c>CModule</c> and a function name <c>CFunction</c>. When a
184
process reaches the breakpoint,
185
<c>CModule:CFunction(Bindings)</c> will be evaluated. If and
186
only if this function call returns <c>true</c>, the process
187
will stop. If the function call returns <c>false</c>,
188
the breakpoint will be silently ignored.</p>
190
<p><c>Bindings</c> is a list of variable bindings. Use
191
the function <c>int:get_binding(Variable,Bindings)</c> to
192
retrieve the value of <c>Variable</c> (given as an atom).
193
The function returns <c>unbound</c> or <c>{value,Value}</c>.</p>
195
<image file="images/cond_break_dialog">
196
<icaption>The Conditional Break Dialog Window.</icaption>
199
<p>Right-clicking the Module entry will open a popup menu from
200
which the appropriate module can be selected.</p>
202
<p>Example: A conditional breakpoint calling
203
<c>c_test:c_break/1</c> is added at line 8 in the module
204
<c>fac</c>. Each time the breakpoint is reached, the function is
205
called, and when <c>N</c> is equal to 3 it returns <c>true</c>,
206
and the process stops.</p>
208
<p>Extract from <c>fac.erl</c>:</p>
214
8. N * fac(N - 1).</pre>
216
<p>Definition of <c>c_test:c_break/1</c>:</p>
219
-export([c_break/1]).
222
case int:get_binding('N', Bindings) of
231
<title>Function Breakpoints</title>
233
<p>A function breakpoint is a set of line breakpoints, one at
234
the first line of each clause in the given function.</p>
236
<image file="images/function_break_dialog">
237
<icaption>The Function Break Dialog Window.</icaption>
240
<p>Right-clicking the Module entry will open a popup menu from
241
which the appropriate module can be selected.</p>
243
<p>Clicking the Ok button (or 'Return' or 'Tab') when a module
244
name has been given, will bring up all functions of the module
250
<marker id="stack_trace"/>
251
<title>Stack Trace</title>
253
<p>The Erlang emulator keeps track of a <em>stack trace</em>,
254
information about recent function calls. This information is
255
used, for example, if an error occurs:</p>
257
1> <input>catch a+1.</input>
258
{'EXIT',{badarith,[{erlang,'+',[a,1]},
259
{erl_eval,do_apply,5},
262
{shell,eval_exprs,6},
263
{shell,eval_loop,3}]}}</pre>
265
<p>In the case above, the stack trace shows that the function called
266
last was <c>erl_eval:eval_op/3</c>. See <em>Erlang Reference
267
Manual, Errors and Error handling</em>, for more information
268
about stack trace.</p>
270
<p>Debugger emulates the stack trace by keeping track of recently
271
called interpreted functions. (The real stack trace cannot be
272
used, as it shows which functions of the Debugger have been
273
called, rather than which interpreted functions).</p>
275
<p>This information can be used to traverse the chain of function
276
calls, using the 'Up' and 'Down' buttons of
277
<seealso marker="#attach">the Attach Process window</seealso>.
280
<p>By default, the Debugger saves information about all current
281
function calls, that is, function calls that have not yet returned
282
a value (option 'Stack On, Tail').</p>
284
<p>This means, however, that information is saved also for tail
285
recursive calls. For example, repeated calls to the <c>loop</c>
286
function of an Erlang process. This may consume unnecessary
287
amounts of memory for debugged processes with long lifetimes and
288
many tail recursive calls. It is therefore possible to set
289
the option 'Stack On, no tail', in which case information about
290
previous calls are discarded when a tail recursive call is made.
293
<p>It is also possible to turn off the Debugger stack trace
294
facility ('Stack Off'). <em>Note:</em> If an error occurs, in this
295
case the stack trace will be empty.</p>
297
<p>See the section about <seealso marker="#monitor">the Monitor
298
Window</seealso> for information about how to change the stack
303
<marker id="monitor"/>
304
<title>The Monitor Window</title>
306
<p>The Monitor window is the main window of Debugger and shows a
307
listbox containing the names of all interpreted modules
308
(double-clicking a module brings up the View Module window),
309
which options are selected, and information about all debugged
310
processes, that is all processes which have been/are executing
311
code in interpreted modules.</p>
313
<image file="images/monitor">
314
<icaption>The Monitor Window.</icaption>
317
<p>The Auto Attach buttons, Stack Trace label and Back Trace Size
318
label show some options set, see
319
<seealso marker="#options">Options Menu</seealso> for further
320
information about these options.</p>
323
<title>Process Grid</title>
326
<tag><em>Pid</em></tag>
327
<item><p>The process identifier.</p></item>
329
<tag><em>Initial Call</em></tag>
330
<item><p>The first call to an interpreted function by this
331
process. (<c>Module:Function/Arity</c>)</p></item>
333
<tag><em>Name</em></tag>
334
<item><p>The registered name, if any. If a registered name does
335
not show up, it may be that the Debugger received
336
information about the process before the name had been
337
registered. Try selecting <em>Edit->Refresh</em>.</p></item>
339
<tag><em>Status</em></tag>
340
<item><p>The current status, one of the following:</p>
342
<tag><em>idle</em></tag>
343
<item><p>The interpreted function call has returned a value,
344
and the process is no longer executing interpreted code.
347
<tag><em>running</em></tag>
348
<item><p>The process is running.</p></item>
350
<tag><em>waiting</em></tag>
351
<item><p>The process is waiting in a <c>receive</c>
352
statement.</p></item>
354
<tag><em>break</em></tag>
355
<item><p>The process is stopped at a breakpoint.</p></item>
357
<tag><em>exit</em></tag>
358
<item><p>The process has terminated.</p></item>
360
<tag><em>no_conn</em></tag>
361
<item><p>There is no connection to the node where
362
the process is located.</p></item>
366
<tag><em>Information</em></tag>
367
<item><p>Additional information, if any. If the process is
368
stopped at a breakpoint, the field contains information
369
about the location <c>{Module,Line}</c>. If the process has
370
terminated, the field contains the exit reason.</p></item>
375
<title>The File Menu</title>
378
<tag><em>Load Settings...</em></tag>
380
<p>Try to load and restore Debugger settings from a file
381
previously saved using <em>Save Settings...</em>, see below.
382
Any errors are silently ignored.</p>
385
<tag><em>Save Settings...</em></tag>
386
<item><p>Save Debugger settings to a file. The settings include
387
the set of interpreted files, breakpoints, and the selected
388
options. The settings can be restored in a later Debugger
389
session using <em>Load Settings...</em>, see above.
390
Any errors are silently ignored.</p>
393
<tag><em>Exit</em></tag>
394
<item><p>Stop Debugger.</p></item>
399
<title>The Edit Menu</title>
401
<tag><em>Refresh</em></tag>
402
<item><p>Update information about debugged processes. Removes
403
information about all terminated processes from the window,
404
and also closes all Attach Process windows for terminated
405
processes.</p></item>
407
<tag><em>Kill All</em></tag>
408
<item><p>Terminate all processes listed in the window using
409
<c>exit(Pid,kill)</c>.</p></item>
414
<title>The Module Menu</title>
416
<tag><em>Interpret...</em></tag>
417
<item><p>Open the <seealso marker="#interpret">Interpret Dialog
418
window</seealso> where new modules to be interpreted can
419
be specified.</p></item>
421
<tag><em>Delete All</em></tag>
422
<item><p>Stop interpreting all modules. Processes executing in
423
interpreted modules will terminate.</p></item>
426
<p>For each interpreted module, a corresponding entry is added to
427
the Module menu, with the following submenu:</p>
429
<tag><em>Delete</em></tag>
430
<item><p>Stop interpreting the selected module. Processes
431
executing in this module will terminate.</p></item>
433
<tag><em>View</em></tag>
434
<item><p>Open a <seealso marker="#view">View Module
435
window</seealso> showing the contents of the selected
441
<title>The Process Menu</title>
442
<p>The following menu items apply to the currently selected
443
process, provided it is stopped at a breakpoint. See the chapter
444
about the <seealso marker="#attach">Attach Process
445
window</seealso> for more information.</p>
447
<tag><em>Step</em></tag><item></item>
448
<tag><em>Next</em></tag><item></item>
449
<tag><em>Continue</em></tag><item></item>
450
<tag><em>Finish</em></tag><item></item>
452
<p>The following menu items apply to the currently selected
455
<tag><em>Attach</em></tag>
456
<item><p>Attach to the process and open a
457
<seealso marker="#attach">Attach Process window</seealso>.
460
<tag><em>Kill</em></tag>
461
<item><p>Terminate the process using <c>exit(Pid,kill)</c>.</p>
467
<title>The Break Menu</title>
468
<p>The items in this menu are used to create and delete
470
See the <seealso marker="#breakpoints">Breakpoints</seealso>
471
chapter for more information.</p>
473
<tag><em>Line Break...</em></tag>
474
<item><p>Set a line breakpoint.</p></item>
476
<tag><em>Conditional Break...</em></tag>
477
<item><p>Set a conditional breakpoint.</p></item>
479
<tag><em>Function Break...</em></tag>
480
<item><p>Set a function breakpoint.</p></item>
482
<tag><em>Enable All</em></tag>
483
<item><p>Enable all breakpoints.</p></item>
485
<tag><em>Disable All</em></tag>
486
<item><p>Disable all breakpoints.</p></item>
488
<tag><em>Delete All</em></tag>
489
<item><p>Remove all breakpoints.</p></item>
492
<p>For each breakpoint, a corresponding entry is added to
494
menu, from which it is possible to disable/enable or delete
495
the breakpoint, and to change its trigger action.</p>
499
<marker id="options"/>
500
<title>The Options Menu</title>
503
<tag><em>Trace Window</em></tag>
504
<item><p>Set which areas should be visible in
505
an <seealso marker="#attach">Attach Process
506
window</seealso>. Does not affect already existing
507
Attach Process windows.</p>
510
<tag><em>Auto Attach</em></tag>
511
<item><p>Set at which events a debugged process should be
512
automatically attached to. Affects existing debugged
515
<item><em>First Call</em> - the first time a process calls a
516
function in an interpreted module.</item>
517
<item><em>On Exit</em> - at process termination.</item>
518
<item><em>On Break</em> - when a process reaches a
523
<tag><em>Stack Trace</em></tag>
524
<item><p>Set stack trace option, see section
525
<seealso marker="#stack_trace">Stack Trace</seealso>. Does not
526
affect already existing debugged processes.</p>
528
<item><em>Stack On, Tail</em> - save information about all
529
current calls.</item>
530
<item><em>Stack On, No Tail</em> - save information about
531
current calls, discarding previous information when a tail
532
recursive call is made.</item>
533
<item><em>Stack Off</em> - do not save any information about
534
current calls.</item>
538
<tag><em>Back Trace Size...</em></tag>
539
<item><p>Set how many call frames should be fetched when
540
inspecting the call stack from the Attach Process window.
541
Does not affect already existing Attach Process windows.</p>
547
<title>The Windows Menu</title>
548
<p>Contains a menu item for each open Debugger window. Selecting
549
one of the items will raise the corresponding window.</p>
553
<title>The Help Menu</title>
555
<tag><em>Help</em></tag>
556
<item><p>View the Debugger documentation. Currently this
557
function requires Netscape to be up and running.</p></item>
563
<marker id="interpret"/>
564
<title>The Interpret Dialog Window</title>
566
<p>The interpret dialog module is used for selecting which modules
567
to interpret. Initially, the window shows the modules (<c>erl</c>
568
files) and subdirectories of the current working directory.</p>
570
<p>Interpretable modules are modules for which a BEAM file, compiled
571
with the option <c>debug_info</c> set, can be found in the same
572
directory as the source code, or in an <c>ebin</c> directory next
575
<p>Modules, for which the above requirements are not fulfilled, are
576
not interpretable and are therefore displayed within parentheses.
579
<p>The <c>debug_info</c> option causes <em>debug information</em> or
580
<em>abstract code</em> to be added to the BEAM file. This will
581
increase the size of the file, and also makes it possible to
582
reconstruct the source code. It is therefore recommended not to
583
include debug information in code aimed for target systems.</p>
585
<p>An example of how to compile code with debug information using
587
<c>% erlc +debug_info module.erl</c></p>
589
<p>An example of how to compile code with debug information from
590
the Erlang shell:<br/>
591
<c>4> c(module, debug_info).</c></p>
593
<image file="images/interpret">
594
<icaption>The Interpret Dialog Window.</icaption>
597
<p>Browse the file hierarchy and interpret the appropriate modules
598
by selecting a module name and pressing <em>Choose</em> (or
599
carriage return), or by double clicking the module name.
600
Interpreted modules are displayed with a * in front of the name.
603
<p>Pressing <em>All</em> will interpret all displayed modules in
604
the chosen directory.</p>
606
<p>Pressing <em>Done</em> will close the window.</p>
609
<p>When the Debugger is started in global mode (which is
611
<seealso marker="debugger:debugger#start/0">debugger:start/0</seealso>),
612
modules added (or deleted) for interpretation will be added (or
613
deleted) on all known Erlang nodes.</p>
618
<marker id="attach"/>
619
<title>The Attach Process Window</title>
621
<p>From an Attach Process window the user can interact with a
622
debugged process. One window is opened for each process that has
623
been attached to. Note that when attaching to a process, its
624
execution is automatically stopped.
627
<image file="images/attach">
628
<icaption>The Attach Process Window.</icaption>
631
<p>The window is divided into five parts:</p>
633
<item><p>The Code area, showing the code being executed. The code
634
is indented and each line is prefixed with its line number.
635
If the process execution is stopped, the current line is
636
marked with <em>--></em>. An existing break point at a line
637
is marked with <em>-@-</em>. In the example above,
638
the execution has been stopped at line 56, before
639
the execution of <c>io:format/2</c>.</p>
640
<p>Active breakpoints are shown in red, while inactive
641
breakpoints are shown in blue.</p>
643
<item>The Button area, with buttons for quick access to frequently
644
used functions in the Process menu.</item>
645
<item>The Evaluator area, where the user can evaluate functions
646
within the context of the debugged process, provided that
647
process execution has been stopped.</item>
648
<item>The Bindings area, showing all variables bindings.
649
Clicking on a variable name will result in the value being
650
displayed in the Evaluator area.
651
Double-clicking on a variable name will open a window where
652
the variable value may be edited. Note however that pid,
653
reference, binary or port values can not be edited.
655
<item><p>The Trace area, showing a trace output for the process.
658
<tag><c>++ (N) <L></c></tag>
659
<item>Function call, where <c>N</c> is the call level and
660
<c>L</c> the line number.</item>
662
<tag><c>-- (N)</c></tag>
663
<item>Function return value.</item>
665
<tag><c>==> Pid : Msg</c></tag>
666
<item>The message <c>Msg</c> is sent to process <c>Pid</c>.
669
<tag><c><![CDATA[<== Msg]]></c></tag>
670
<item>The message <c>Msg</c> is received.</item>
672
<tag><c>++ (N) receive</c></tag>
673
<item>Waiting in a <c>receive</c>.</item>
675
<tag><c>++ (N) receive with timeout</c></tag>
676
<item>Waiting in a <c>receive...after</c>.</item>
679
<p>Also the back trace, a summary of the current function calls
680
on the stack, is displayed in the Trace area.</p>
684
<p>It is configurable using the Options menu which areas should
685
be shown or hidden. By default, all areas except the Trace area
689
<title>The File Menu</title>
692
<tag><em>Close</em></tag>
693
<item><p>Close this window and detach from the process.</p>
699
<title>The Edit Menu</title>
702
<tag><em>Go to line...</em></tag>
703
<item><p>Go to a specified line number.</p></item>
705
<tag><em>Search...</em></tag>
706
<item><p>Search for a specified string.</p></item>
711
<title>The Process Menu</title>
714
<tag><em>Step</em></tag>
715
<item><p>Execute the current line of code, stepping into any
716
(interpreted) function calls.</p></item>
718
<tag><em>Next</em></tag>
719
<item><p>Execute the current line of code and stop at the next
722
<tag><em>Continue</em></tag>
723
<item><p>Continue the execution.</p></item>
725
<tag><em>Finish</em></tag>
726
<item><p>Continue the execution until the current function
729
<tag><em>Skip</em></tag>
730
<item><p>Skip the current line of code and stop at the next
731
line. If used on the last line in a function body,
732
the function will return <c>skipped</c>.</p></item>
734
<tag><em>Time Out</em></tag>
735
<item><p>Simulate a timeout when executing a
736
<c>receive...after</c> statement.</p></item>
738
<tag><em>Stop</em></tag>
739
<item><p>Stop the execution of a running process, that is, make
740
the process stop as at a breakpoint. The command will take
741
effect (visibly) the next time the process receives a
744
<tag><em>Where</em></tag>
745
<item><p>Make sure the current location of the execution is
746
visible in the code area.</p></item>
748
<tag><em>Kill</em></tag>
749
<item><p>Terminate the process using <c>exit(Pid,kill)</c>.</p>
752
<tag><em>Messages</em></tag>
753
<item><p>Inspect the message queue of the process. The queue is
754
printed in the evaluator area.</p></item>
756
<tag><em>Back Trace</em></tag>
757
<item><p>Display the back trace of the process, a summary of
758
the current function calls on the stack, in the trace area.
759
Requires that the Trace area is visible and that the stack
760
trace option is 'Stack On, Tail' or 'Stack On, No Tail'.</p>
763
<tag><em>Up</em></tag>
764
<item><p>Inspect the previous function call on the stack,
765
showing the location and variable bindings.</p></item>
767
<tag><em>Down</em></tag>
768
<item><p>Inspect the next function call on the stack, showing
769
the location and variable bindings.</p></item>
774
<title>The Options Menu</title>
777
<tag><em>Trace Window</em></tag>
778
<item><p>Set which areas should be visible. Does not affect
779
other Attach Process windows.</p>
782
<tag><em>Stack Trace</em></tag>
783
<item><p>Same as in <seealso marker="#monitor">the Monitor
784
window</seealso>, but does only affect the debugged
785
process the window is attached to.</p>
788
<tag><em>Back Trace Size...</em></tag>
789
<item><p>Set how many call frames should be fetched when
790
inspecting the call stack. Does not affect other Attach
797
<title>Break, Windows and Help Menus</title>
799
<p>The Break, Windows and Help menus look the same as in
800
the Monitor window, see the chapter
801
<seealso marker="#monitor">The Monitor Window</seealso>, except
802
that the Breaks menu apply to the local breakpoints only.</p>
808
<title>The View Module Window</title>
810
<p>The View Module window shows the contents of an interpreted
811
module and makes it possible to set breakpoints.</p>
813
<image file="images/view">
814
<icaption>The View Module Window.</icaption>
817
<p>The source code is indented and each line is prefixed with its
820
<p>Clicking a line will highlight it and select it to be the target
821
of the breakpoint functions available from the Break menu.
822
Doubleclicking a line will set a line breakpoint on that line.
823
Doubleclicking a line with an existing breakpoint will remove
826
<p>Breakpoints are marked with <em>-@-</em>.</p>
829
<title>File and Edit Menus</title>
830
<p>The File and Edit menus look the same as in the Attach Process
831
window, see the chapter <seealso marker="#attach">The Attach
832
Process Window</seealso>.</p>
836
<title>Break, Windows and Help Menus</title>
838
<p>The Break, Windows and Help menus look the same as in
839
the Monitor window, see the chapter
840
<seealso marker="#monitor">The Monitor Window</seealso>, except
841
that the Breaks menu apply to the local breakpoints only.</p>
846
<title>Performance</title>
848
<p>Execution of interpreted code is naturally slower than for
849
regularly compiled modules. Using the Debugger also increases
850
the number of processes in the system, as for each debugged
851
process another process (the meta process) is created.</p>
853
<p>It is also worth to keep in mind that programs with timers may
854
behave differently when debugged. This is especially true when
855
stopping the execution of a process, for example at a
856
breakpoint. Timeouts can then occur in other processes that
857
continue execution as normal.</p>
861
<title>Code Loading Mechanism</title>
863
<p>Code loading works almost as usual, except that interpreted
864
modules are also stored in a database and debugged processes
865
uses only this stored code. Re-interpreting an interpreted
866
module will result in the new version being stored as well, but
867
does not affect existing processes executing an older version
868
of the code. This means that the code replacement mechanism of
869
Erlang does not work for debugged processes.</p>
873
<title>Debugging Remote Nodes</title>
875
<p>By using <c>debugger:start/1</c>, it can be specified if Debugger
876
should be started in local or global mode.</p>
878
debugger:start(local | global)</pre>
879
<p>If no argument is provided, Debugger is started in global mode.
882
<p>In local mode, code is interpreted only at the current node.
883
In global mode, code is interpreted at all known nodes. Processes
884
at other nodes executing interpreted code will automatically be
885
shown in the Monitor window and can be attached to like any other
886
debugged process.</p>
888
<p>It is possible, but definitely not recommended to start Debugger
889
in global mode on more than one node in a network, as they will
890
interfer with each other leading to inconsistent behaviour.</p>
added
removed
lib/debugger/doc/src/debugger_chapter.xml
