From 2a0e30cb155b80273eb43bc0e01376b68a5fb5b0 Mon Sep 17 00:00:00 2001 From: Lukas Larsson Date: Thu, 17 Mar 2016 16:02:16 +0100 Subject: runtime_tools: Lots of dbg docs updates --- lib/runtime_tools/doc/src/dbg.xml | 281 ++++++++++++++++++++++---------------- 1 file changed, 165 insertions(+), 116 deletions(-) (limited to 'lib/runtime_tools/doc/src/dbg.xml') diff --git a/lib/runtime_tools/doc/src/dbg.xml b/lib/runtime_tools/doc/src/dbg.xml index 0232cc0453..ccb3bca50e 100644 --- a/lib/runtime_tools/doc/src/dbg.xml +++ b/lib/runtime_tools/doc/src/dbg.xml @@ -36,14 +36,30 @@ The Text Based Trace Facility

This module implements a text based interface to the - trace/3 and the trace_pattern/2 BIFs. It makes it - possible to trace functions, processes and messages on text based - terminals. It can be used instead of, or as complement to, the - pman module. -

-

For some examples of how to use dbg from the Erlang + trace/3 and the + trace_pattern/2 BIFs. It makes it + possible to trace functions, processes, ports and messages. +

+

+ To quickly get started on tracing function calls you can use the following + code in the Erlang shell: +

+ 
+1> dbg:tracer(). %% Start the default trace message receiver
+{ok,<0.36.0>}
+2> dbg:p(all, c). %% Setup call (c) tracing on all processes
+{ok,[{matched,nonode@nohost,26}]}
+3> dbg:tp(lists, seq, x). %% Setup an exception return trace (x) on lists:seq
+{ok,[{matched,nonode@nohost,2},{saved,x}]}
+4> lists:seq(1,10).
+(<0.34.0>) call lists:seq(1,10)
+(<0.34.0>) returned from lists:seq/2 -> [1,2,3,4,5,6,7,8,9,10]
+[1,2,3,4,5,6,7,8,9,10]
+
+

+ For more examples of how to use dbg from the Erlang shell, see the simple example section. -

+

The utilities are also suitable to use in system testing on large systems, where other tools have too much impact on the system performance. Some primitive support for sequential tracing @@ -164,53 +180,66 @@ Error: fun containing local erlang function calls ('is_atomm' called in guard)\

Traces Item in accordance to the value specified by Flags. The variation of Item is listed below:

- - If the Item is a pid(), the corresponding - process is traced. The process may be a remote process - (on another Erlang node). The node must be in the list of - traced nodes (see n/1 and - tracer/0/2/3). - If the Item is the atom all, all processes in the - system as well as all processes created hereafter are - to be traced. This also affects all nodes added with the - n/1 or tracer/0/2/3 function. - If the Item is the atom new, no currently existing - processes are affected, but every process created after the - call is.This also affects all nodes added with the - n/1 or tracer/0/2/3 function. - If the Item is the atom existing, all - existing processes are traced, but new processes will not - be affected.This also affects all nodes added with the - n/1 or tracer/0/2/3 function. - If the Item is an atom other than all, - new or existing, the process with the - corresponding registered name is traced.The process may be a - remote process (on another Erlang node). The node must be added - with the n/1 or tracer/0/2/3 function. - If the Item is an integer, the process ]]> is - traced. - If the Item is a tuple {X, Y, Z}, the - process ]]> is - traced. + + pid() or port() + The corresponding process or port is traced. The process or port may + be a remote process or port (on another Erlang node). The node must + be in the list of traced nodes (see n/1 + and tracer/3). + all + All processes and ports in the system as well as all processes and ports + created hereafter are to be traced. + all_processes + All processes in the system as well as all processes created hereafter are to be traced. + all_ports + All ports in the system as well as all ports created hereafter are to be traced. + new + All processes and ports created after the call is are to be traced. + new_processes + All processes created after the call is are to be traced. + new_ports + All ports created after the call is are to be traced. + existing + All existing processes and ports are traced. + existing_processes + All existing processes are traced. + existing_ports + All existing ports are traced. + atom() + The process or port with the corresponding registered name is traced. The process or + port may be a remote process (on another Erlang node). The node must be + added with the n/1 or + tracer/3 function. + integer() + The process ]]> is traced. + {X, Y, Z} + The process ]]> is traced. + string() If the Item is a string "]]> - as returned from pid_to_list/1, the process + as returned from pid_to_list/1, the process ]]> is traced. - + + +

When enabling an Item that represents a group of processes, + the Item is enabled on all nodes added with the + n/1 or + tracer/3 function.

+

Flags can be a single atom, or a list of flags. The available flags are:

s (send) -

Traces the messages the process sends.

+

Traces the messages the process or port sends.

 r (receive) -

Traces the messages the process receives.

+

Traces the messages the process or port receives.

 m (messages) -

Traces the messages the process receives and sends.

+

Traces the messages the process or port receives and sends.

 c (call) @@ -221,6 +250,10 @@ Error: fun containing local erlang function calls ('is_atomm' called in guard)\

Traces process related events to the process.

 + ports + +

Traces port related events to the port.

+ sos (set on spawn)

Lets all processes created by the traced @@ -241,8 +274,8 @@ Error: fun containing local erlang function calls ('is_atomm' called in guard)\ sofl (set on first link)

This is the same as sol, but only for - the first call to - link/1 by the traced process.

+ the first call to + link/1 by the traced process.

 all @@ -258,7 +291,7 @@ Error: fun containing local erlang function calls ('is_atomm' called in guard)\ erlang:trace/3

The function returns either an error tuple or a tuple {ok, List}. The List consists of - specifications of how many processes that matched (in the + specifications of how many processes and ports that matched (in the case of a pure pid() exactly 1). The specification of matched processes is {matched, Node, N}. If the remote processor call,rpc, to a remote node fails, @@ -286,9 +319,9 @@ Error: fun containing local erlang function calls ('is_atomm' called in guard)\ i() -> ok - Display information about all traced processes. + Display information about all traced processes and ports. -

Displays information about all traced processes.

+

Displays information about all traced processes and ports.

@@ -327,35 +360,41 @@ Error: fun containing local erlang function calls ('is_atomm' called in guard)\

This function enables call trace for one or more - functions. All exported functions matching the {Module, Function, Arity} argument will be concerned, but the + functions. All exported functions matching the {Module, Function, Arity} + argument will be concerned, but the match_spec() may further narrow down the set of function calls generating trace messages.

For a description of the match_spec() syntax, please turn to the User's guide part of the online documentation for the runtime system (erts). The - chapter Match Specification in Erlang explains the - general match specification "language".

+ chapter Match Specifications in Erlang + explains the general match specification "language". + The most common generic match specifications used can be + found as Built-inAlias', see + ltp/0 below for details. +

The Module, Function and/or Arity parts of the tuple may be specified as the atom '_' which is a "wild-card" matching all modules/functions/arities. Note, if the Module is specified as '_', the Function and Arity parts have to be specified as '_' too. The same holds for the Functions relation to the Arity.

-

All nodes added with n/1 or tracer/0/2/3 will +

All nodes added with n/1 or + tracer/3 will be affected by this call, and if Module is not '_' the module will be loaded on all nodes.

The function returns either an error tuple or a tuple {ok, List}. The List consists of specifications of how - many functions that matched, in the same way as the processes - are presented in the return value of p/2.

+ many functions that matched, in the same way as the processes and ports + are presented in the return value of p/2.

There may be a tuple {saved, N} in the return value, if the MatchSpec is other than []. The integer N may then be used in subsequent calls to this function and will stand as an "alias" for the given expression. There are also a couple of - built-in aliases for common expressions, see ltp/0 below - for details.

+ built-in aliases for common expressions, see + ltp/0 below for details.

If an error is returned, it can be due to errors in compilation of the match specification. Such errors are presented as a list of tuples {error, string()} where @@ -394,7 +433,7 @@ Error: fun containing local erlang function calls ('is_atomm' called in guard)\ tpl({Module, Function, Arity}, MatchSpec) -> {ok, MatchDesc} | {error, term()} Set pattern for traced local (as well as global) function calls -

This function works as tp/2, but enables +

This function works as tp/2, but enables tracing for local calls (and local functions) as well as for global calls (and functions).

 @@ -441,10 +480,10 @@ Error: fun containing local erlang function calls ('is_atomm' called in guard)\

This function disables call tracing on the specified functions. The semantics of the parameter is the same as for the corresponding function specification in - tp/2 or tpl/2. Both local and global call trace + tp/2 or tpl/2. Both local and global call trace is disabled.

The return value reflects how many functions that matched, - and is constructed as described in tp/2. No tuple + and is constructed as described in tp/2. No tuple {saved, N} is however ever returned (for obvious reasons).

 @@ -480,8 +519,8 @@ Error: fun containing local erlang function calls ('is_atomm' called in guard)\ ctpl({Module, Function, Arity}) -> {ok, MatchDesc} | {error, term()} Clear call trace pattern for the specified functions -

This function works as ctp/1, but only disables - tracing set up with tpl/2 (not with tp/2).

+

This function works as ctp/1, but only disables + tracing set up with tpl/2 (not with tp/2).

 @@ -516,8 +555,8 @@ Error: fun containing local erlang function calls ('is_atomm' called in guard)\ ctpg({Module, Function, Arity}) -> {ok, MatchDesc} | {error, term()} Clear call trace pattern for the specified functions -

This function works as ctp/1, but only disables - tracing set up with tp/2 (not with tpl/2).

+

This function works as ctp/1, but only disables + tracing set up with tp/2 (not with tpl/2).

 @@ -526,13 +565,13 @@ Error: fun containing local erlang function calls ('is_atomm' called in guard)\

Use this function to recall all match specifications previously used in the session (i. e. previously saved during calls - to tp/2, and built-in match specifications. + to tp/2, and built-in match specifications. This is very useful, as a complicated match_spec can be quite awkward to write. Note that the - match specifications are lost if stop/0 is called.

+ match specifications are lost if stop/0 is called.

Match specifications used can be saved in a file (if a read-write file system is present) for use in later - debugging sessions, see wtp/1 and rtp/1

+ debugging sessions, see wtp/1 and rtp/1

There are three built-in trace patterns: exception_trace, caller_trace and caller_exception_trace (or x, c and @@ -555,10 +594,10 @@ Error: fun containing local erlang function calls ('is_atomm' called in guard)\ Delete all saved match specifications.

Use this function to "forget" all match specifications - saved during calls to tp/2. + saved during calls to tp/2. This is useful when one wants to restore other match - specifications from a file with rtp/1. Use - dtp/1 to delete specific saved match specifications.

+ specifications from a file with rtp/1. Use + dtp/1 to delete specific saved match specifications.

@@ -569,7 +608,7 @@ Error: fun containing local erlang function calls ('is_atomm' called in guard)\

Use this function to "forget" a specific match specification - saved during calls to tp/2.

+ saved during calls to tp/2.

 @@ -581,12 +620,12 @@ Error: fun containing local erlang function calls ('is_atomm' called in guard)\

This function will save all match specifications saved - during the session (during calls to tp/2) + during the session (during calls to tp/2) and built-in match specifications in a text file with the name designated by Name. The format of the file is textual, why it can be edited with an ordinary text editor, and then restored with - rtp/1.

+ rtp/1.

Each match spec in the file ends with a full stop (.) and new (syntactically correct) match specifications can be added to the file manually.

@@ -604,7 +643,7 @@ Error: fun containing local erlang function calls ('is_atomm' called in guard)\

This function reads match specifications from a file - (possibly) generated by the wtp/1 function. It checks + (possibly) generated by the wtp/1 function. It checks the syntax of all match specifications and verifies that they are correct. The error handling principle is "all or nothing", i. e. if some of the match specifications are @@ -612,14 +651,14 @@ Error: fun containing local erlang function calls ('is_atomm' called in guard)\ saved match specifications for the running system.

The match specifications in the file are merged with the current match specifications, so that no duplicates - are generated. Use ltp/0 to see what numbers were + are generated. Use ltp/0 to see what numbers were assigned to the specifications from the file.

The function will return an error, either due to I/O problems (like a non existing or non readable file) or due to file format problems. The errors from a bad format file are in a more or less textual format, which will give a hint - to what's causing the problem. -

+ to what's causing the problem. +

@@ -631,12 +670,12 @@ Error: fun containing local erlang function calls ('is_atomm' called in guard)\

The dbg server keeps a list of nodes where tracing - should be performed. Whenever a tp/2 call or a - p/2 call is made, it is executed for all nodes in this - list including the local node (except for p/2 with a - specific pid() as first argument, in which case the + should be performed. Whenever a tp/2 call or a + p/2 call is made, it is executed for all nodes in this + list including the local node (except for p/2 with a + specific pid() or port() as first argument, in which case the command is executed only on the node where the designated - process resides). + process or port resides).

This function adds a remote node (Nodename) to the list of nodes where tracing is performed. It starts a tracer @@ -645,17 +684,17 @@ Error: fun containing local erlang function calls ('is_atomm' called in guard)\ distribution). If no tracer process is running on the local node, the error reason no_local_tracer is returned. The tracer process on the local node must be started with the - tracer/0/2 function. + tracer/0/2 function.

If Nodename is the local node, the error reason cant_add_local_node is returned.

-

If a trace port (see trace_port/2) is +

If a trace port (see trace_port/2) is running on the local node, remote nodes can not be traced with a tracer process. The error reason cant_trace_remote_pid_to_local_port is returned. A trace port can however be started on the remote node with the - tracer/3 function. + tracer/3 function.

The function will also return an error if the node Nodename is not reachable.

@@ -669,7 +708,7 @@ Error: fun containing local erlang function calls ('is_atomm' called in guard)\

Clears a node from the list of traced nodes. Subsequent - calls to tp/2 and p/2 will not consider that + calls to tp/2 and p/2 will not consider that node, but tracing already activated on the node will continue to be in effect.

Returns ok, cannot fail.

@@ -688,37 +727,42 @@ Error: fun containing local erlang function calls ('is_atomm' called in guard)\

This function starts a server on the local node that will be the recipient of all trace messages. All subsequent calls - to p/2 will result in messages sent to the newly + to p/2 will result in messages sent to the newly started trace server.

A trace server started in this way will simply display the trace messages in a formatted way in the Erlang shell - (i. e. use io:format). See tracer/2 for a description - of how the trace message handler can be customized. -

-

To start a similar tracer on a remote node, use n/1.

+ (i. e. use io:format). See tracer/2 for a description + of how the trace message handler can be customized. +

+

To start a similar tracer on a remote node, use n/1.

 tracer(Type, Data) -> {ok, pid()} | {error, Error} Start a tracer server with additional parameters - Type = port | process - Data = PortGenerator | HandlerSpec - HandlerSpec = {HandlerFun, InitialData} - HandlerFun = fun() (two arguments) - InitialData = term() + Type = port | process | module + Data = PortGenerator | HandlerSpec | ModuleSpec PortGenerator = fun() (no arguments) Error = term() + HandlerSpec = {HandlerFun, InitialData} + HandlerFun = fun() (two arguments) + ModuleSpec = {TracerModule, TracerState} + ModuleModule = atom() + InitialData = TracerState = term()

This function starts a tracer server with additional parameters on the local node. The first parameter, the Type, indicates if trace messages should be handled - by a receiving process (process) or by a tracer port - (port). For a description about tracer ports see - trace_port/2. + by a receiving process (process), by a tracer port + (port) or by a tracer module + (module). For a description about tracer ports see + trace_port/2 + and for a tracer modules see + erl_tracer.

-

If Type is a process, a message handler function can +

If Type is process, a message handler function can be specified (HandlerSpec). The handler function, which should be a fun taking two arguments, will be called for each trace message, with the first argument containing the @@ -729,18 +773,22 @@ Error: fun containing local erlang function calls ('is_atomm' called in guard)\ choose any appropriate action to take when invoked, and can save a state for the next invocation by returning it.

-

If Type is a port, then the second parameter should +

If Type is port, then the second parameter should be a fun which takes no arguments and returns a newly opened trace port when called. Such a fun is - preferably generated by calling trace_port/2. + preferably generated by calling trace_port/2.

+

if Type is module, then the second parameter should + be a tuple describing the erl_tracer + module to be used for tracing and the state to be used for + that tracer module.

If an error is returned, it can either be due to a tracer server already running ({error,already_started}) or due to the HandlerFun throwing an exception.

To start a similar tracer on a remote node, use - tracer/3. -

+ tracer/3. +

@@ -750,20 +798,20 @@ Error: fun containing local erlang function calls ('is_atomm' called in guard)\ Nodename = atom() -

This function is equivalent to tracer/2, but acts on +

This function is equivalent to tracer/2, but acts on the given node. A tracer is started on the node (Nodename) and the node is added to the list of traced nodes.

-

This function is not equivalent to n/1. While - n/1 starts a process tracer which redirects all trace +

This function is not equivalent to n/1. While + n/1 starts a process tracer which redirects all trace information to a process tracer on the local node (i.e. the - trace control node), tracer/3 starts a tracer of any + trace control node), tracer/3 starts a tracer of any type which is independent of the tracer on the trace control node.

 -

For details, see tracer/2.

+

For details, see tracer/2.

 @@ -795,9 +843,9 @@ Error: fun containing local erlang function calls ('is_atomm' called in guard)\ file and the ip trace drivers. The file driver sends all trace messages into one or several binary files, from where they later can be fetched and processed with the - trace_client/2 function. The ip driver opens a TCP/IP + trace_client/2 function. The ip driver opens a TCP/IP port where it listens for connections. When a client - (preferably started by calling trace_client/2 on + (preferably started by calling trace_client/2 on another Erlang node) connects, all trace messages are sent over the IP network for further processing by the remote client.

@@ -836,7 +884,7 @@ Error: fun containing local erlang function calls ('is_atomm' called in guard)\ as fast as they are produced by the runtime system, a special message is sent, which indicates how many messages that are dropped. That message will arrive at the handler function - specified in trace_client/3 as the tuple {drop, N} where N is the number of consecutive messages + specified in trace_client/3 as the tuple {drop, N} where N is the number of consecutive messages dropped. In case of heavy tracing, drop's are likely to occur, and they surely occur if no client is reading the trace messages.

@@ -890,7 +938,7 @@ Error: fun containing local erlang function calls ('is_atomm' called in guard)\ get_listen_port -

Returns {ok, IpPort} where IpPortis +

Returns {ok, IpPort} where IpPort is the IP port number used by the driver listen socket. Only the ip trace driver supports this operation.

 @@ -913,7 +961,7 @@ Error: fun containing local erlang function calls ('is_atomm' called in guard)\

This function starts a trace client that reads the output created by a trace port driver and handles it in mostly the - same way as a tracer process created by the tracer/0 + same way as a tracer process created by the tracer/0 function.

If Type is file, the client reads all trace messages stored in the file named Filename or @@ -925,7 +973,7 @@ Error: fun containing local erlang function calls ('is_atomm' called in guard)\

If Type is follow_file, the client behaves as in the file case, but keeps trying to read (and process) more data - from the file until stopped by stop_trace_client/1. + from the file until stopped by stop_trace_client/1. WrapFilesSpec is not allowed as second argument for this Type.

If Type is ip, the client connects to the @@ -981,10 +1029,10 @@ hello InitialData = term() -

This function works exactly as trace_client/2, but +

This function works exactly as trace_client/2, but allows you to write your own handler function. The handler function works mostly as the one described in - tracer/2, but will also have to be prepared to handle + tracer/2, but will also have to be prepared to handle trace messages of the form {drop, N}, where N is the number of dropped messages. This pseudo trace message will only occur if the ip trace driver is used.

@@ -1003,7 +1051,7 @@ hello

This function shuts down a previously started trace client. The Pid argument is the process id returned - from the trace_client/2 or trace_client/3 call.

+ from the trace_client/2 or trace_client/3 call.

 @@ -1156,8 +1204,9 @@ SeqTrace [0]: (<0.30.0>) <0.25.0> ! {dbg,{ok,<0.31.0>}} [Serial: {4,5}] of causing a deadlock. This will happen if a group leader process generates a trace message and the tracer process, by calling the trace handler function, sends an IO request to the same group leader. The problem can only occur if the trace handler - prints to tty using an io function such as format/2. Note that when - dbg:p(all,call) is called, IO processes are also traced. + prints to tty using an io function such as format/2. + Note that when + dbg:p(all,call) is called, IO processes are also traced. Here's an example:

 %% Using a default line editing shell
-- 
cgit v1.2.3