diff options
Diffstat (limited to 'lib/observer/doc/src')
25 files changed, 2318 insertions, 1658 deletions
diff --git a/lib/observer/doc/src/Makefile b/lib/observer/doc/src/Makefile index 0f564d3299..b38278a156 100644 --- a/lib/observer/doc/src/Makefile +++ b/lib/observer/doc/src/Makefile @@ -1,13 +1,14 @@ -# ``The contents of this file are subject to the Erlang Public License, -# Version 1.1, (the "License"); you may not use this file except in -# compliance with the License. You should have received a copy of the -# Erlang Public License along with this software. If not, it can be -# retrieved via the world wide web at http://www.erlang.org/. -# -# Software distributed under the License is distributed on an "AS IS" -# basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See -# the License for the specific language governing rights and limitations -# under the License. +# ``Licensed under the Apache License, Version 2.0 (the "License"); +# you may not use this file except in compliance with the License. +# You may obtain a copy of the License at +# +# http://www.apache.org/licenses/LICENSE-2.0 +# +# Unless required by applicable law or agreed to in writing, software +# distributed under the License is distributed on an "AS IS" BASIS, +# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. +# See the License for the specific language governing permissions and +# limitations under the License. # # The Initial Developer of the Original Code is Ericsson Utvecklings AB. # Portions created by Ericsson are Copyright 1999, Ericsson Utvecklings @@ -34,6 +35,8 @@ RELSYSDIR = $(RELEASE_PATH)/lib/$(APPLICATION)-$(VSN) # Target Specs # ---------------------------------------------------- XML_APPLICATION_FILES = ref_man.xml +XML_REF1_FILES = \ + cdv.xml XML_REF3_FILES = \ crashdump.xml \ observer.xml \ @@ -59,19 +62,14 @@ BOOK_FILES = book.xml XML_FILES = \ $(BOOK_FILES) $(XML_CHAPTER_FILES) \ - $(XML_PART_FILES) $(XML_REF3_FILES) \ + $(XML_PART_FILES) $(XML_REF1_FILES) $(XML_REF3_FILES) \ $(XML_APPLICATION_FILES) $(XML_REF6_FILES) -ONLY_HTML_FILE = \ - crashdump_help.html +ONLY_HTML_FILE = GIF_FILES = \ et_processes.gif \ et_modsprocs.gif \ - etop_main.gif \ - etop_5.gif \ - etop_lines.gif \ - etop_opt.gif \ note.gif # ---------------------------------------------------- @@ -81,6 +79,7 @@ HTML_FILES = $(XML_APPLICATION_FILES:%.xml=$(HTMLDIR)/%.html) \ INFO_FILE = ../../info +MAN1_FILES = $(XML_REF1_FILES:%.xml=$(MAN1DIR)/%.1) MAN3_FILES = $(XML_REF3_FILES:%.xml=$(MAN3DIR)/%.3) MAN6_FILES = $(XML_REF6_FILES:%_app.xml=$(MAN6DIR)/%.6) @@ -110,6 +109,7 @@ html: gifs $(HTML_REF_MAN_FILE) $(ONLY_HTML_FILE:%=$(HTMLDIR)/%) clean clean_docs: rm -rf $(HTMLDIR)/* + rm -f $(MAN1DIR)/* rm -f $(MAN3DIR)/* rm -f $(MAN6DIR)/* rm -f $(TOP_PDF_FILE) $(TOP_PDF_FILE:%.pdf=%.fo) @@ -119,7 +119,7 @@ clean clean_docs: $(HTMLDIR)/$(ONLY_HTML_FILE): $(INSTALL_DATA) $(ONLY_HTML_FILE) $@ -man: $(MAN3_FILES) $(MAN6_FILES) +man: $(MAN1_FILES) $(MAN3_FILES) $(MAN6_FILES) gifs: $(GIF_FILES:%=$(HTMLDIR)/%) @@ -139,6 +139,8 @@ release_docs_spec: docs $(INSTALL_DATA) $(HTMLDIR)/* \ "$(RELSYSDIR)/doc/html" $(INSTALL_DATA) $(INFO_FILE) "$(RELSYSDIR)" + $(INSTALL_DIR) "$(RELEASE_PATH)/man/man1" + $(INSTALL_DATA) $(MAN1DIR)/* "$(RELEASE_PATH)/man/man1" $(INSTALL_DIR) "$(RELEASE_PATH)/man/man3" $(INSTALL_DATA) $(MAN3DIR)/* "$(RELEASE_PATH)/man/man3" $(INSTALL_DIR) "$(RELEASE_PATH)/man/man6" diff --git a/lib/observer/doc/src/book.xml b/lib/observer/doc/src/book.xml index 7ecb153b2f..7cc60718b1 100644 --- a/lib/observer/doc/src/book.xml +++ b/lib/observer/doc/src/book.xml @@ -1,23 +1,24 @@ -<?xml version="1.0" encoding="latin1" ?> +<?xml version="1.0" encoding="utf-8" ?> <!DOCTYPE book SYSTEM "book.dtd"> <book xmlns:xi="http://www.w3.org/2001/XInclude"> <header titlestyle="normal"> <copyright> - <year>2002</year><year>2009</year> + <year>2002</year><year>2016</year> <holder>Ericsson AB. All Rights Reserved.</holder> </copyright> <legalnotice> - The contents of this file are subject to the Erlang Public License, - Version 1.1, (the "License"); you may not use this file except in - compliance with the License. You should have received a copy of the - Erlang Public License along with this software. If not, it can be - retrieved online at http://www.erlang.org/. - - Software distributed under the License is distributed on an "AS IS" - basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See - the License for the specific language governing rights and limitations - under the License. + Licensed under the Apache License, Version 2.0 (the "License"); + you may not use this file except in compliance with the License. + You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an "AS IS" BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. </legalnotice> diff --git a/lib/observer/doc/src/cdv.xml b/lib/observer/doc/src/cdv.xml new file mode 100644 index 0000000000..df1032780a --- /dev/null +++ b/lib/observer/doc/src/cdv.xml @@ -0,0 +1,61 @@ +<?xml version="1.0" encoding="utf-8" ?> +<!DOCTYPE comref SYSTEM "comref.dtd"> + +<comref> + <header> + <copyright> + <year>2003</year><year>2016</year> + <holder>Ericsson AB. All Rights Reserved.</holder> + </copyright> + <legalnotice> + Licensed under the Apache License, Version 2.0 (the "License"); + you may not use this file except in compliance with the License. + You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an "AS IS" BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. + + </legalnotice> + + <title>The cdv program</title> + <prepared>Siri Hansen</prepared> + <responsible>Siri Hansen</responsible> + <docno></docno> + <approved></approved> + <checked></checked> + <date>2013-10-015</date> + <rev>PA1</rev> + <file>cdv.xml</file> + </header> + <com>cdv</com> + <comsummary>Script to start the Crashdump Viewer from the + OS command line. + </comsummary> + + <description> + <p>The <c>cdv</c> shell script is located in directory <c>priv</c> + of the Observer application. The script is used + for starting the Crashdump Viewer tool from the OS command + line.</p> + <p>For Windows users, <c>cdv.bat</c> is found in the same + location.</p> + </description> + + <funcs> + <func> + <name>cdv [file]</name> + <fsummary>Start the Crashdump Viewer and load the given file.</fsummary> + <desc> + <p>Argument <c>file</c> is optional. If not specified, a file + dialog is displayed, allowing you to select a crashdump + from the file system.</p> + </desc> + </func> + </funcs> + +</comref> diff --git a/lib/observer/doc/src/crashdump.xml b/lib/observer/doc/src/crashdump.xml index b6056c2ed1..48f944cbce 100644 --- a/lib/observer/doc/src/crashdump.xml +++ b/lib/observer/doc/src/crashdump.xml @@ -1,61 +1,72 @@ -<?xml version="1.0" encoding="latin1" ?> +<?xml version="1.0" encoding="utf-8" ?> <!DOCTYPE erlref SYSTEM "erlref.dtd"> <erlref> <header> <copyright> <year>2003</year> - <year>2011</year> + <year>2016</year> <holder>Ericsson AB, All Rights Reserved</holder> </copyright> <legalnotice> - The contents of this file are subject to the Erlang Public License, - Version 1.1, (the "License"); you may not use this file except in - compliance with the License. You should have received a copy of the - Erlang Public License along with this software. If not, it can be - retrieved online at http://www.erlang.org/. + Licensed under the Apache License, Version 2.0 (the "License"); + you may not use this file except in compliance with the License. + You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 - Software distributed under the License is distributed on an "AS IS" - basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See - the License for the specific language governing rights and limitations - under the License. + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an "AS IS" BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. The Initial Developer of the Original Code is Ericsson AB. </legalnotice> <title>crashdump_viewer</title> - <prepared>Siri hansen</prepared> + <prepared>Siri Hansen</prepared> <responsible></responsible> <docno>1</docno> <approved></approved> <checked></checked> <date>2003-03-10</date> <rev>PA1</rev> - <file>crashdump.sgml</file> + <file>crashdump.xml</file> </header> <module>crashdump_viewer</module> - <modulesummary>A HTML based tool for browsing Erlang crashdumps.</modulesummary> + <modulesummary>A WxWidgets based tool for browsing Erlang + crashdumps.</modulesummary> <description> - <p>The Crashdump Viewer is an HTML based tool for browsing Erlang - crashdumps. Crashdump Viewer runs under the WebTool application.</p> + <p>The Crashdump Viewer is a WxWidgets based tool for browsing Erlang + crashdumps.</p> - <p>See the <seealso marker="crashdump_ug">user's guide</seealso> - for more information about how to get started with the Crashdump - Viewer.</p> + <p>For details about how to get started with the Crashdump Viewer, see the + <seealso marker="crashdump_ug"><c>User's Guide</c></seealso>.</p> </description> <funcs> <func> <name>start() -> ok</name> - <fsummary>Start the crashdump_viewer</fsummary> + <name>start(File) -> ok</name> + <fsummary>Start the Crashdump Viewer.</fsummary> + <type> + <v>File = string()</v> + <d>The filename of the crashdump.</d> + </type> <desc> - <p>This function starts the <c>crashdump_viewer</c>.</p> + <p>Starts the Crashdump Viewer GUI and + loads the specified crashdump.</p> + + <p>If <c>File</c> is not specified, a file dialog is opened + where the crashdump can be selected.</p> </desc> </func> <func> <name>stop() -> ok</name> - <fsummary>Stop the crashdump_viewer</fsummary> + <fsummary>Terminate the Crashdump Viewer.</fsummary> <desc> - <p>This function stops the <c>crashdump_viewer</c>.</p> + <p>Terminates the Crashdump Viewer and closes + all GUI windows.</p> </desc> </func> </funcs> diff --git a/lib/observer/doc/src/crashdump_help.html b/lib/observer/doc/src/crashdump_help.html deleted file mode 100644 index 268b9495d6..0000000000 --- a/lib/observer/doc/src/crashdump_help.html +++ /dev/null @@ -1,307 +0,0 @@ -</<!doctype chapter PUBLIC "-//Stork//DTD chapter//EN"> -<!-- - ``The contents of this file are subject to the Erlang Public License, - Version 1.1, (the "License"); you may not use this file except in - compliance with the License. You should have received a copy of the - Erlang Public License along with this software. If not, it can be - retrieved via the world wide web at http://www.erlang.org/. - - Software distributed under the License is distributed on an "AS IS" - basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See - the License for the specific language governing rights and limitations - under the License. - - The Initial Developer of the Original Code is Ericsson Utvecklings AB. - Portions created by Ericsson are Copyright 1999, Ericsson Utvecklings - AB. All Rights Reserved.'' - - $Id$ ---> -<html> -<head> -<title>Crashdump Viewer help</title> -</head> -<body BGCOLOR="#FFFFFF"> -<center> -<a HREF="http://www.erlang.se"><img BORDER=0 ALT="[Erlang Systems]" -SRC="min_head.gif"></a> -</center> -<blockquote> - <h2>Information pages</h2> - - <p>Each menu item points to an information page. If no information - is found for an item, the page will simply say "No information - found". The reason for not finding any information about an item - can be that the dump is truncated, that it is a dump from an old - OTP release in which this item was not written or that the item - simply wasn't present in the system at the point of failure. - - <p>If the dump was truncated, a warning is displayed. - - <p>Even if some information about an item exists, there might be - empty fields if the dump originates from an old OTP release. - - <p>The value "-1" in any field means "unknown", and in most cases - it means that the dump was truncated somewhere around this field. - - <p>Only some of the fields in the different information pages are - described here. These are fields that to not exist in the raw - crashdump, or in some way differs from the fields in the raw - crashdump. Details about other field can be found in the user's - guide for the Erlang runtime system, in the chapter "How to - interpret the Erlang crash dumps". A link to this chapter can be - found in the Crashdump Viewer's menu under documentation, and - there are also direct links from the specific sections below to - related information in "How to interpret the Erlang crash dumps". - - <a NAME="general_info"> - <h3>General information</h3> - - <p>This is the first page shown when a new dump is loaded into - the system. It shows a very short overview of the dump. - - <p>'Node name' will only exist in dumps originating from OTP R9C - and later. - - <p>The following fields are not described in the Erlang runtime - system user's guide: - - <dl> - <dt><strong>Crashdump created on</strong></dt> - <dd>Time of failure.</dd> - - <dt><strong>Memory allocated</strong></dt> - <dd>The total number of bytes allocated, equivalent to - <code>c:memory(total)</code>. This will only be present in - dumps from OTP R9C and later.</dd> - - <dt><strong>Memory maximum</strong></dt> - <dd>The maximum number of bytes that has been allocated - during the lifetime of the originating node. This will not be - present in dumps older than OTP R9C, and even in newer - releases it is only shown if the Erlang runtime system was run - instrumented.</dd> - - <dt><strong>Atoms</strong></dt> - <dd>If at all available in the dump, this is the total - number of atoms in the atom table. If the size of the atom - table is not available, the number of atoms visible in the - dump is presented.</dd> - - <dt><strong>Processes, ETS tables and Funs</strong></dt> - <dd>The number of processes, ETS tables and funs visible in - the dump.</dd> - </dl> - - <center> - <a href=/crashdump_erts_doc/crash_dump.html#general_info> - More...</a> - </center> - - - <a NAME="processes"> - <h3>Processes</h3> - - <p>The Process Information page shows a list of all processes - found in the crashdump, including some short information about - each process. By default the processes are sorted by their - pids. To sort by other topic, click any heading in the process - table. - - <p>Detailed information about a specific process is shown when - the pid is clicked. - - <center> - <a href=/crashdump_erts_doc/crash_dump.html#processes> - More...</a> - </center> - - - - <a NAME="ports"> - <h3>Ports</h3> - - <p>The port information page shows all port information found in - the dump. - - <center> - <a href=/crashdump_erts_doc/crash_dump.html#ports> - More...</a> - </center> - - - - <a NAME="ets_tables"><a NAME="internal_ets_tables"> - <h3>ETS tables</h3> - - <p>The ETS table information page shows all ETS table - information found in the dump. The 'Id' is the same as the - 'Table' field found in the raw crashdump, and 'Memory' is the - 'Words' field from the raw crashdump translated into - bytes. 'Type' is the type of table, and it can be either "hash" - or "tree". For tree tables there will be no value in the - 'Bucket' field. - - <p>Clicking a pid in the 'Owner' column takes you to the - detailed information about the process owning the ETS table. - - <center> - <a href=/crashdump_erts_doc/crash_dump.html#ets_tables> - More...</a> - </center> - - - <a NAME="timers"> - <h3>Timers</h3> - - <p>The timer information page shows all timer information found - in the dump. - - <p>Clicking a pid in the 'Owner' column takes you to the - detailed information about the process owning the timer. - - <center> - <a href=/crashdump_erts_doc/crash_dump.html#timers> - More...</a> - </center> - - - - <a NAME="funs"> - <h3>Fun table</h3> - - <p>The Fun table information page shows all Fun information - found in the dump. Fun information will only exist in dumps from - OTP R8B or later. - - <center> - <a href=/crashdump_erts_doc/crash_dump.html#funs> - More...</a> - </center> - - - - <a NAME="atoms"> - <h3>Atoms</h3> - - <p>The atoms information page lists all atoms found in the - dump. The last created atom is listed first. - - <p>Note that if the dump is from OTP R8B or earlier, the raw - dump lists the atoms in the opposite order and the Crashdump - Viewer reverses them. This means that there is no problem if the - dump is not truncated. However, if the dump is truncated, the - last atoms might not be shown at all!! - - <center> - <a href=/crashdump_erts_doc/crash_dump.html#atoms> - More...</a> - </center> - - - <a NAME="distribution_info"> - <h3>Distribution information</h3> - - <p>The distribution information page shows all distribution - information found in the dump. - - <p>If the page shows "Not alive", it means that the node was not - distributed. - - <p>It the node was distributed, all connected nodes are - shown. Visible nodes are alive nodes with a living connection to - the originating node. Hidden nodes are the same as visible - nodes, except they are started with the "-hidden" flag. Not - connected nodes are nodes that are not connected to the - originating node anymore, but references (i.e. process or port - identitifiers) exist. - - <p>'Links/Monitors' may contain information about links or - monitors between processes on the originating node and the - connected node. - - <p>'Extra Info' may contain debug information (i.e. special - information written if the emulator is debug compiled) or error - information. - - <center> - <a href=/crashdump_erts_doc/crash_dump.html#distribution_info> - More...</a> - </center> - - - <a NAME="loaded_modules"> - <h3>Loaded modules</h3> - - <p>The loaded modules information page shows all modules that - were loaded on the originating node, and the current size of the - code. If old code exsits, the old size is also shown. - - <p>Detailed information about a specific module is shown when - the module name is clicked. - - <center> - <a href=/crashdump_erts_doc/crash_dump.html#loaded_modules> - More...</a> - </center> - - - <a NAME="internal_tables"> - <h3>Internal tables</h3> - - <p>Internal tables are shown in two information pages: hash - tables and index tables. - - <center> - <a href=/crashdump_erts_doc/crash_dump.html#internal_tables> - More...</a> - </center> - - - <a NAME="memory"> - <h3>Memory</h3> - - <p>Memory information is divided into three pages. - - <p>The first page, <strong>Memory</strong>, shows information - similar to what you can obtain on a living node with - <code>c:memory()</code>. This will only be present in dumps from - OTP R9C and later. - <a href=/crashdump_erts_doc/crash_dump.html#memory>More...</a> - - <p>The <strong>Allocated areas</strong> page shows information - similar to what you can obtain on a living node with - <code>erlang:system_info(allocated_areas)</code>. - <a href=/crashdump_erts_doc/crash_dump.html#allocated_areas>More...</a> - - <p>The <strong>Allocator information</strong> page shows - information about allocators. The contents of the page will vary - with the version. - <a href=/crashdump_erts_doc/crash_dump.html#allocator>More...</a> - - <center> - - </center> - - - <h3>Documentation</h3> - - <p>'Crashdump Viewer help' is this document. - - <p>'How to interpret Erlang crashdumps' is a document from the - Erlang runtime system describing details in the raw - crashdumps. Here you will also find information about each - single field in the different information pages. - -</blockquote> -<center> -<hr> -<font SIZE=-1> - -Copyright © 1991-2003 -<a HREF="http://www.erlang.se">Ericsson Utvecklings AB</a><br> -<!--#include virtual="/ssi/otp_footer.html"--> -</font> -</center> -</body> -</html> diff --git a/lib/observer/doc/src/crashdump_ug.xml b/lib/observer/doc/src/crashdump_ug.xml index 8aef1ffdf0..4ba057c3fb 100644 --- a/lib/observer/doc/src/crashdump_ug.xml +++ b/lib/observer/doc/src/crashdump_ug.xml @@ -1,24 +1,24 @@ -<?xml version="1.0" encoding="latin1" ?> +<?xml version="1.0" encoding="utf-8" ?> <!DOCTYPE chapter SYSTEM "chapter.dtd"> <chapter> <header> <copyright> - <year>2003</year><year>2013</year> + <year>2003</year><year>2016</year> <holder>Ericsson AB. All Rights Reserved.</holder> </copyright> <legalnotice> - The contents of this file are subject to the Erlang Public License, - Version 1.1, (the "License"); you may not use this file except in - compliance with the License. You should have received a copy of the - Erlang Public License along with this software. If not, it can be - retrieved online at http://www.erlang.org/. - - Software distributed under the License is distributed on an "AS IS" - basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See - the License for the specific language governing rights and limitations - under the License. - + Licensed under the Apache License, Version 2.0 (the "License"); + you may not use this file except in compliance with the License. + You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an "AS IS" BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. </legalnotice> <title>Crashdump Viewer</title> @@ -31,104 +31,398 @@ <section> <title>Introduction</title> - <p>The Crashdump Viewer is an HTML based tool for browsing Erlang - crashdumps. Crashdump Viewer runs under the WebTool application. - </p> + <p>The Crashdump Viewer is a WxWidgets based tool for browsing + Erlang crashdumps. + </p> </section> <section> <title>Getting Started</title> - <p>The easiest way to start Crashdump Viewer is to use the - provided shell script named <c>cdv</c> with the full path to the - erlang crashdump as an argument. The script can be found in the - priv directory of the <c>observer</c> application. This starts - WebTool, Crashdump Viewer and a web browser, and loads the given - file. The browser should then display a page named General - Information which shows a short summary of the information in - the crashdump.</p> - - <p>The default browser is Internet Explorer on Windows, open on Mac OS X, - or else Firefox. To use another browser, give the browser's start command - as the second argument to <c>cdv</c>. If the given browser name is - not known to Crashdump Viewer, the browser argument is executed as - a command with the start URL as the only argument.</p> - - <p>Under Windows the batch file <c>cdv.bat</c> can be used.</p> - - <p>It is also possible to start the Crashdump Viewer from within - an erlang node by calling <seealso - marker="crashdump_viewer#start/0">crashdump_viewer:start/0</seealso>. This - will automatically start WebTool and display the web address where - WebTool can be found. See the documentation for the WebTool - application for further information about how to use WebTool.</p> - - <p>Point your web browser to the address displayed, and you should - now see the start page of WebTool. At the top of the page, you - will see a link to "CrashDumpViewer". Click this link to get to - the start page for Crashdump Viewer. (Note that if webtool is on - localhost, you must configure your web browser to have direct - connection to the internet, or you must set no proxy for - localhost.) - </p> - <p>From the start page of Crashdump Viewer, push the "Load - Crashdump" button to load a crashdump into the tool. Then enter - the filename of the crashdump in the entry field and push the - "Ok" button. This will bring you to the General Information - page, i.e. the same page as the <c>cdv</c> script will open in - the browser. - </p> - <p>Crashdumps generated by OTP R9C and later are loaded directly - into the Crashdump Viewer, while dumps from earlier releases first - are translated by the Crashdump Translater. The Crashdump - Translater creates a new file with the same name as the original - crashdump, but with the extension <c>.translated</c>. If there is - no write access to the directory of the original file, you will be - asked to enter a new path and filename for the translated file. - </p> - </section> - - <section> - <title>Navigating</title> - <p>The lefthand frame contains a menu. Menu folders can be - expanded and collapsed by clicking the folder picture. When a menu - item is clicked, the item information is shown in the big - information frame. - </p> - <p>The filename frame above the information frame shows the full - name of the currently viewed Erlang crashdump. - </p> - <p>To load a new crashdump, click the "Load New Crashdump" button - in the menu frame. - </p> - <p>The various information shown in the information frame will - contain links to process identifiers (PIDs) and port - identifiers. Clicking one of these links will take you to the - detailed information page for the process or port in question. Use - the "Back" button in your browser to get back to the - startingpoint. If the process or port resided on a remote node, - there will be no information available. Clicking the link will - then take you to the information about the remote node. - </p> - </section> - - <section> - <title>Help</title> - <p>Further help on how to use the Crashdump Viewer tool can be - found in the tool's menu under 'Documentation': - </p> - <p>'Crashdump Viewer help' is a short document describing each - information page and any additional information that might occur, - compared to the raw dump described in 'How to interpret Erlang - crashdumps'. - </p> - <p>'How to interpret Erlang crashdumps' is a document from the - Erlang runtime system describing details in the raw - crashdumps. Here you will also find information about each single - field in the different information pages. This document can also - be found directly in the OTP online documentation, via the Erlang - runtime system user's guide. - </p> + <p>The easiest way to start Crashdump Viewer is to use + shell script <c>cdv</c> with the full path to the + Erlang crashdump as argument. The script is located in + directory <c>priv</c> of the Observer application. This starts the + Crashdump Viewer GUI and loads the specified file. If no filename is + specified, a file dialog is opened where the file can be + selected.</p> + + <p>Under Windows, the batch file <c>cdv.bat</c> can be used.</p> + + <p>Crashdump Viewer can also be started from + an Erlang node by calling <seealso + marker="crashdump_viewer#start/0">crashdump_viewer:start/0</seealso> + or <seealso + marker="crashdump_viewer#start/1">crashdump_viewer:start/1</seealso>.</p> </section> -</chapter> + <section> + <title>GUI</title> + + <p>The GUI main window is opened when Crashdump Viewer has loaded a + crashdump. It contains a title bar, a menu bar, + information tabs, and a status bar.</p> + + <p>The title bar shows the name of the currently loaded + crashdump.</p> + + <p>The menu bar contains a <em>File</em> menu and a <em>Help</em> + menu. From the <em>File</em> menu, a new crashdump can be loaded or + the tool can be terminated. From the <em>Help</em> menu, this User's Guide + and section "How to interpret the Erlang crash dumps" from the + ERTS application can be opened. "How to interpret + the Erlang crash dumps" describes the raw crashdumps in + detail and includes information about each + field in the information pages."How to interpret the Erlang crash dumps" + is also available in the OTP online documentation.</p> + + <p>The status bar at the bottom of the window shows a warning + if the currently loaded dump is truncated.</p> + + <p>The center area of the main window contains the information + tabs. Each tab displays information about a specific item or a + list of items. Select a tab by clicking the tab title.</p> + + <p>From tabs displaying lists of items, for example, the + <em>Processes</em> tab or the <em>Ports</em> tab, a new window with + more information can be opened by double-clicking a row or by right- + clicking the row and selecting an item from the drop-down + menu. The new window is called a detail window. Detail windows can + be opened for processes, ports, nodes, and modules.</p> + + <p>The information shown in a detail window can contain + links to processes or ports. Clicking one of these links opens + the detail window for the process or port in question. If the + process or port resides on a remote node, no + information is available. Clicking the link then displays a dialog + where you can choose to open the detail window for the + remote node. + </p> + + <p>Some tabs contain a left-hand menu where subitems of + the information area can be selected. Click one of the + rows, and the information is displayed in the right-hand + information area.</p> + </section> + + <section> + <title>Tab Content</title> + + <p>Each tab in the main window contains an information + page. If no information is found for an item, the page is + empty. The reason for not finding information about an item + can be the following:</p> + <list type="bulleted"> + <item>It is a dump from an old OTP release in which this item was not written.</item> + <item>The item was not present in the system at the point of failure.</item> + <item>The dump is truncated. In this case, a warning is displayed in the + status bar of the main window.</item> + </list> + + <p></p> + + <p>Even if some information about an item exists, there can be + empty fields if the dump originates from an old OTP release.</p> + + <p>The value <c>-1</c> in any field means "unknown", and in most + cases it means that the dump was truncated somewhere around this + field.</p> + + <p>The following sections describe some of the fields in the + information tabs. These are fields that do not exist + in the raw crashdump, or in some way differ from the fields in + the raw crashdump. For details about other fields, see + the + <seealso marker="erts:users_guide">ERTS User's Guide</seealso>, section + "How to interpret the Erlang crash dumps". That section can also + be opened from the <em>Help</em> menu in the main window. + There are also links from the following sections to related information + in "How to interpret the Erlang crash dumps".</p> + </section> + + <section> + <marker id="general_info"/> + <title>General Tab</title> + + <p>Tab <em>General</em> shows a short overview + of the dump.</p> + + <p>The following fields are not described in the ERTS + User's Guide:</p> + + <taglist> + <tag><c>Crashdump created on</c></tag> + <item><p>Time of failure.</p></item> + + <tag><c>Memory allocated</c></tag> + <item><p>The total number of bytes allocated, equivalent to + <c>c:memory(total)</c>.</p></item> + + <tag><c>Memory maximum</c></tag> + <item><p>The maximum number of bytes that has been allocated during + the lifetime of the originating node. This is only shown if + the Erlang runtime system is run instrumented.</p></item> + + <tag><c>Atoms</c></tag> + <item><p>If available in the dump, this is the total number of + atoms in the atom table. If the size of the atom table is + unavailable, the number of atoms visible in the dump is + displayed.</p></item> + + <tag><c>Processes</c></tag> + <item><p>The number of processes visible in the dump.</p></item> + + <tag><c>ETS tables</c></tag> + <item><p>The number of ETS tables visible in the dump.</p></item> + + <tag><c>Funs</c></tag> + <item><p>The number of funs visible in the dump.</p></item> + </taglist> + + <p>For details, see + <seealso marker="erts:crash_dump#general_info">General Information</seealso> + in section "How to Interpret the Erlang Crash Dumps" in ERTS. + </p> + </section> + + <section> + <marker id="processes"/> + <title>Processes Tab</title> + + <p>Tab <em>Processes</em> shows a list of all processes + found in the crashdump, including brief information about + each process. By default, the processes are sorted by their + pids. To sort by another topic, click the desired column heading.</p> + + <p>Column <em>Memory</em> shows the 'Memory' field that was + added to crashdumps in Erlang/OTP R16B01. This is the total amount of memory + used by the process. For crashdumps from earlier releases, this + column shows the 'Stack+heap' field. The value is always in bytes.</p> + + <p>To view detailed information about a specific process, double- + click the row in the list, or right-click the row and select + <em>Properties for <pid></em>.</p> + + <p>For details, see + <seealso marker="erts:crash_dump#processes">Process Information</seealso> + in section "How to Interpret the Erlang Crash Dumps" in ERTS. + </p> + </section> + + <section> + <marker id="ports"/> + <title>Ports Tab</title> + + <p>Tab <em>Ports</em> is similar to the <em>Processes</em> + tab, except it lists all ports found in the crashdump.</p> + + <p>To view more details about a specific port, double-click the row + or right-click it and select <em>Properties for <port></em>. From + the right-click menu, you can also select <em>Properties for + <pid></em>, where <c><pid></c> is the process connected to the + port.</p> + + <p>For details, see + <seealso marker="erts:crash_dump#ports">Port Information</seealso> + in section "How to Interpret the Erlang Crash Dumps" in ERTS. + </p> + </section> + + <section> + <marker id="ets_tables"/><marker id="internal_ets_tables"/> + <title>ETS Tables Tab</title> + + <p>Tab <em>ETS Tables</em> shows all ETS table information + found in the dump. <em>Id</em> is the same as the 'Table' field + in the raw crashdump. <em>Memory</em> is the 'Words' field from the + raw crashdump translated into bytes. For tree tables, there is + no value in the 'Objects' field.</p> + + <p>To open the detailed information page about the table, double- + click, or right-click the row and select <em>Properties for + 'Identifier'</em>.</p> + + <p>To open the detailed information page about the owner process + of an ETS table, right-click the row and select <em>Properties for + <pid></em>.</p> + + <p>For details, see + <seealso marker="erts:crash_dump#ets_tables">ETS Tables</seealso> + in section "How to Interpret the Erlang Crash Dumps" in ERTS. + </p> + </section> + + <section> + <marker id="timers"/> + <title>Timers Tab</title> + + <p>Tab <em>Timers</em> shows all timer information found in + the dump.</p> + + <p>To open the detailed information page about the owner process + of a timer, right-click the row and select <em>Properties for + <pid></em>.</p> + + <p>Double-clicking a row in the <em>Timers</em> tab has no effect.</p> + + <p>For details, see + <seealso marker="erts:crash_dump#timers">Timers</seealso> + in section "How to Interpret the Erlang Crash Dumps" in ERTS. + </p> + </section> + + <section> + <marker id="schedulers"/> + <title>Schedulers Tab</title> + + <p>Tab <em>Schedulers</em> shows all scheduler information + found in the dump.</p> + + <p>To open the detailed information page about the scheduler, + double-click, or right-click the row and select <em>Properties for + 'Identifier'</em>.</p> + + <p>For details, see + <seealso marker="erts:crash_dump#scheduler">Scheduler Information</seealso> + in section "How to Interpret the Erlang Crash Dumps" in ERTS. + </p> + </section> + + <section> + <marker id="funs"/> + <title>Funs Tab</title> + + <p>Tab <em>Funs</em> shows all fun information found in the + dump.</p> + + <p>To open the detailed information page about the module to which + the fun belongs, right-click the row and select <em>Properties for + <mod></em>.</p> + + <p>Double-clicking a row in the <em>Funs</em> tab has no effect.</p> + + <p>For details, see + <seealso marker="erts:crash_dump#funs">Fun Information</seealso> + in section "How to Interpret the Erlang Crash Dumps" in ERTS. + </p> + </section> + + <section> + <marker id="atoms"/> + <title>Atoms Tab</title> + + <p>Tab <em>Atoms</em> lists all atoms found in the dump. By + default the atoms are sorted in creation order from first to + last. This is opposite of the raw crashdump where atoms are listed + from last to first, meaning that if the dump was truncated in the + middle of the atom list, only the last created atoms are visible + in the <em>Atoms</em> tab.</p> + + <p>For details, see + <seealso marker="erts:crash_dump#atoms">Atoms</seealso> + in section "How to Interpret the Erlang Crash Dumps" in ERTS. + </p> + </section> + + <section> + <marker id="distribution_info"/> + <title>Nodes Tab</title> + + <p>Tab <em>Nodes</em> shows a list of all external Erlang + nodes that are referenced from the crashdump.</p> + + <p>If the page is empty, it means either of the following:</p> + <list type="bulleted"> + <item>The crashed node is not distributed.</item> + <item>The crashed node is distributed but has no references to other nodes.</item> + <item>The dump is truncated.</item> + </list> + + <p>If the node is distributed, all referenced nodes are + visible. Column <em>Connection type</em> shows if the node + is visible, hidden, or not connected. Visible nodes are alive nodes + with a living connection to the originating node. Hidden nodes are + the same as visible nodes, except they are started with flag + <c>-hidden</c>. Not connected nodes are nodes that are not + connected to the originating node anymore, but references + (that is, process or port identifiers) exist.</p> + + <p>To see more detailed information about a node, double-click the + row, or right-click the row and select <em>Properties for node + <node></em>. From the right-click menu, you can also select + <em>Properties for <port></em>, to open the detailed information + window for the controlling port.</p> + + <p>In the detailed information window for a node, any existing + links and monitors between processes on the originating node and + the connected node are displayed. <em>Extra Info</em> can contain + debug information (that is, special information written if the + emulator is debug-compiled) or error information.</p> + + <p>For details, see + <seealso marker="erts:crash_dump#distribution_info">Distribution Information</seealso> + in section "How to Interpret the Erlang Crash Dumps" in ERTS. + </p> + </section> + + <section> + <marker id="loaded_modules"/> + <title>Modules Tab</title> + + <p>Tab <em>Modules</em> lists all modules loaded + on the originating node, and the current code size. If old + code exists, the old size is also shown.</p> + + <p>To view detailed information about a specific module, double- + click the row, or right-click it and select <em>Properties for + <mod></em>.</p> + + <p>For details, see + <seealso marker="erts:crash_dump#loaded_modules">Loaded Module Information</seealso> + in section "How to Interpret the Erlang Crash Dumps" in ERTS. + </p> + </section> + + <section> + <marker id="memory"/> + <title>Memory Tab</title> + + <p>Tab <em>Memory</em> shows memory and allocator + information. From the left-hand menu you can select the following:</p> + + <taglist> + <tag><em>Memory</em></tag> + <item><p>See + <seealso marker="erts:crash_dump#memory">Memory Information</seealso> + in section "How to Interpret the Erlang Crash Dumps" in ERTS.</p></item> + + <tag><em>Allocator Summary</em></tag> + <item><p>This page presents a summary of values from all allocators underneath it.</p></item> + + <tag><em><Allocator></em></tag> + <item><p>One entry per allocator. See + <seealso marker="erts:crash_dump#allocator">Allocator</seealso> + in section "How to Interpret the Erlang Crash Dumps" in ERTS.</p></item> + + <tag><em>Allocated Areas</em></tag> + <item><p>See + <seealso marker="erts:crash_dump#allocated_areas">Allocated Areas</seealso> + in section "How to Interpret the Erlang Crash Dumps" in ERTS.</p></item> + + </taglist> + </section> + + <section> + <marker id="internal_tables"/> + <title>Internal Tables Tab</title> + + <p>On tab <em>Internal Tables</em> you can from the + left-hand menu select <em>Hash Tables</em>, <em>Index Tables</em>, + or <em>Internal ETS Tables</em>.</p> + + <p>For details, see + <seealso marker="erts:crash_dump#internal_tables">Internal Table Information</seealso> + in section "How to Interpret the Erlang Crash Dumps" in ERTS. + </p> + </section> +</chapter> diff --git a/lib/observer/doc/src/etop.xml b/lib/observer/doc/src/etop.xml index af6bb2442b..d70d9d1d23 100644 --- a/lib/observer/doc/src/etop.xml +++ b/lib/observer/doc/src/etop.xml @@ -1,30 +1,31 @@ -<?xml version="1.0" encoding="latin1" ?> +<?xml version="1.0" encoding="utf-8" ?> <!DOCTYPE erlref SYSTEM "erlref.dtd"> <erlref> <header> <copyright> <year>2002</year> - <year>2012</year> + <year>2016</year> <holder>Ericsson AB, All Rights Reserved</holder> </copyright> <legalnotice> - The contents of this file are subject to the Erlang Public License, - Version 1.1, (the "License"); you may not use this file except in - compliance with the License. You should have received a copy of the - Erlang Public License along with this software. If not, it can be - retrieved online at http://www.erlang.org/. + Licensed under the Apache License, Version 2.0 (the "License"); + you may not use this file except in compliance with the License. + You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 - Software distributed under the License is distributed on an "AS IS" - basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See - the License for the specific language governing rights and limitations - under the License. + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an "AS IS" BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. The Initial Developer of the Original Code is Ericsson AB. </legalnotice> <title>etop</title> - <prepared>Siri hansen</prepared> + <prepared>Siri Hansen</prepared> <responsible></responsible> <docno></docno> <approved></approved> @@ -34,96 +35,79 @@ <file></file> </header> <module>etop</module> - <modulesummary>Erlang Top is a tool for presenting information about erlang processes similar to the information presented by "top" in UNIX.</modulesummary> + <modulesummary>Erlang Top is a tool for presenting information about Erlang + processes similar to the information presented by "top" in UNIX.</modulesummary> <description> - <p><c>etop</c> should be started with the provided scripts - <c>etop</c> and <c>getop</c> for text based and graphical - presentation respectively. This will start a hidden erlang node - which connects to the node to be measured. The measured node is - given with the <c>-node</c> option. If the measured node has a + <p>Start Erlang Top with the provided scripts + <c>etop</c>. This starts a hidden Erlang node + that connects to the node to be measured. The measured node is + specified with option <c>-node</c>. If the measured node has a different cookie than the default cookie for the user who - invokes the script, the cookie must be explicitly given witht - the <c>-setcookie</c> option.</p> + invokes the script, the cookie must be explicitly specified with + option <c>-setcookie</c>.</p> - <p>Under Windows the batch files <c>etop.bat</c> and - <c>getop.bat</c> can be used.</p> + <p>Under Windows, batch file <c>etop.bat</c> can be used.</p> - <p>The following configuration parameters exist for the - <c>etop</c> tool. When executing the <c>etop</c> or <c>getop</c> - scripts, these parameters can be given as command line options, - e.g. <c>getop -node testnode@myhost -setcookie MyCookie</c>.</p> + <p>When executing the <c>etop</c> script, configuration + parameters can be specified as command-line options, + for example, <c>etop -node testnode@myhost -setcookie MyCookie</c>. + The following configuration parameters exist for the + tool:</p> <taglist> - <tag>node</tag> - <item>The measured node. - <br></br> -Value: atom() - <br></br> -Mandatory</item> - <tag>setcookie</tag> - <item>Cookie to use for the etop node - must be the same - as the cookie on the measured node. - <br></br> -Value: atom()</item> - <tag>lines</tag> - <item>Number of lines (processes) to display. - <br></br> -Value: integer() - <br></br> -Default: 10</item> - <tag>interval</tag> - <item>The time interval (in seconds) between each update of - the display. - <br></br> -Value: integer() - <br></br> -Default: 5</item> - <tag>accumulate</tag> - <item>If <c>true</c> the execution time and reductions are - accumulated. - <br></br> -Value: boolean() - <br></br> -Default: <c>false</c></item> - <tag>sort</tag> - <item>Identifies what information to sort by. - <br></br> -Value: <c>runtime | reductions | memory | msg_q</c> <br></br> -Default: <c>runtime</c> (<c>reductions</c> if - <c>tracing=off</c>)</item> - <tag>tracing</tag> - <item><c>etop</c> uses the erlang trace facility, and thus no + <tag><c>node</c></tag> + <item><p>The measured node.</p> + <p>Value: <c>atom()</c></p> + <p>Mandatory</p></item> + <tag><c>setcookie</c></tag> + <item><p>Cookie to use for the <c>etop</c> node. Must be same as the + cookie on the measured node.</p> + <p>Value: <c>atom()</c></p></item> + <tag><c>lines</c></tag> + <item><p>Number of lines (processes) to display.</p> + <p>Value: <c>integer()</c></p> + <p>Default: <c>10</c></p></item> + <tag><c>interval</c></tag> + <item><p>Time interval (in seconds) between each update of + the display.</p> + <p>Value: <c>integer()</c></p> + <p>Default: <c>5</c></p></item> + <tag><c>accumulate</c></tag> + <item><p>If <c>true</c>, the execution time and reductions are + accumulated.</p> + <p>Value: <c>boolean()</c></p> + <p>Default: <c>false</c></p></item> + <tag><c>sort</c></tag> + <item><p>Identifies what information to sort by.</p> + <p>Value: <c>runtime | reductions | memory | msg_q</c></p> + <p>Default: <c>runtime</c> (<c>reductions</c> if <c>tracing=off</c>)</p></item> + <tag><c>tracing</c></tag> + <item><p><c>etop</c> uses the Erlang trace facility, and thus no other tracing is possible on the measured node while <c>etop</c> is running, unless this option is set to <c>off</c>. Also helpful if the <c>etop</c> tracing causes too high load on the measured node. With tracing off, runtime is - not measured. - <br></br> -Value: <c>on | off</c> <br></br> -Default: <c>on</c></item> + not measured.</p> + <p>Value: <c>on | off</c></p> + <p>Default: <c>on</c></p></item> </taglist> - <p>All interaction with <c>etop</c> when running the graphical - presentation should happen via the menus. For the text based - presentation the functions described below can be used. - </p> - - <p>See the <seealso marker="etop_ug">user's guide</seealso> for - more information about the <c>etop</c> tool.</p> + <p>For detalis about Erlang Top, see the + <seealso marker="etop_ug">User's Guide</seealso>.</p> </description> <funcs> <func> <name>start() -> ok</name> - <fsummary>Start etop</fsummary> + <fsummary>Start etop.</fsummary> <desc> - <p>This function starts <c>etop</c>. - Note that etop is preferably started with the etop and getop scripts</p> + <p>Starts <c>etop</c>. + Notice that <c>etop</c> is preferably started with the <c>etop</c> script.</p> </desc> </func> <func> <name>start(Options) -> ok</name> - <fsummary>Start etop</fsummary> + <fsummary>Start etop.</fsummary> <type> <v>Options = [Option]</v> <v>Option = {Key, Value}</v> @@ -131,31 +115,30 @@ Default: <c>on</c></item> <v>Value = term()</v> </type> <desc> - <p>This function starts <c>etop</c>. Use - <seealso marker="#help/0">help/0</seealso> to see a - description of the possible options.</p> + <p>Starts <c>etop</c>. To view the possible options, use + <seealso marker="#help/0"><c>help/0</c></seealso>.</p> </desc> </func> <func> <name>help() -> ok</name> - <fsummary>Print etop's help</fsummary> + <fsummary>Display the etop help.</fsummary> <desc> - <p>This function prints the help of <c>etop</c> and + <p>Displays the help of <c>etop</c> and its options.</p> </desc> </func> <func> <name>config(Key,Value) -> Result</name> - <fsummary>Change tool's configuration</fsummary> + <fsummary>Change the configuration of the tool.</fsummary> <type> <v>Result = ok | {error,Reason}</v> <v>Key = lines | interval | accumulate | sort</v> <v>Value = term()</v> </type> <desc> - <p>This function is used to change the tool's configuration - parameters during runtime. The table above indicates the - allowed values for each parameter.</p> + <p>Changes the configuration parameters of the tool during runtime. + Allowed parameters are <c>lines</c>, <c>interval</c>, <c>accumulate</c>, + and <c>sort</c>.</p> </desc> </func> <func> @@ -166,14 +149,14 @@ Default: <c>on</c></item> <v>File = string()</v> </type> <desc> - <p>This function dumps the current display to a text file.</p> + <p>Dumps the current display to a text file.</p> </desc> </func> <func> <name>stop() -> stop</name> - <fsummary>Terminate etop</fsummary> + <fsummary>Terminate etop.</fsummary> <desc> - <p>This function terminates <c>etop</c>.</p> + <p>Terminates <c>etop</c>.</p> </desc> </func> </funcs> diff --git a/lib/observer/doc/src/etop_5.gif b/lib/observer/doc/src/etop_5.gif Binary files differdeleted file mode 100644 index 9650176366..0000000000 --- a/lib/observer/doc/src/etop_5.gif +++ /dev/null diff --git a/lib/observer/doc/src/etop_lines.gif b/lib/observer/doc/src/etop_lines.gif Binary files differdeleted file mode 100644 index 10620a1155..0000000000 --- a/lib/observer/doc/src/etop_lines.gif +++ /dev/null diff --git a/lib/observer/doc/src/etop_main.gif b/lib/observer/doc/src/etop_main.gif Binary files differdeleted file mode 100644 index 699cb986c8..0000000000 --- a/lib/observer/doc/src/etop_main.gif +++ /dev/null diff --git a/lib/observer/doc/src/etop_opt.gif b/lib/observer/doc/src/etop_opt.gif Binary files differdeleted file mode 100644 index e420bff7f6..0000000000 --- a/lib/observer/doc/src/etop_opt.gif +++ /dev/null diff --git a/lib/observer/doc/src/etop_ug.xml b/lib/observer/doc/src/etop_ug.xml index ccbb626465..d663b089c2 100644 --- a/lib/observer/doc/src/etop_ug.xml +++ b/lib/observer/doc/src/etop_ug.xml @@ -1,23 +1,24 @@ -<?xml version="1.0" encoding="latin1" ?> +<?xml version="1.0" encoding="utf-8" ?> <!DOCTYPE chapter SYSTEM "chapter.dtd"> <chapter> <header> <copyright> - <year>2002</year><year>2009</year> + <year>2002</year><year>2016</year> <holder>Ericsson AB. All Rights Reserved.</holder> </copyright> <legalnotice> - The contents of this file are subject to the Erlang Public License, - Version 1.1, (the "License"); you may not use this file except in - compliance with the License. You should have received a copy of the - Erlang Public License along with this software. If not, it can be - retrieved online at http://www.erlang.org/. - - Software distributed under the License is distributed on an "AS IS" - basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See - the License for the specific language governing rights and limitations - under the License. + Licensed under the Apache License, Version 2.0 (the "License"); + you may not use this file except in compliance with the License. + You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an "AS IS" BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. </legalnotice> @@ -31,17 +32,25 @@ <section> <title>Introduction</title> - <p>Erlang Top, <c>etop</c> is a tool for presenting information - about erlang processes similar to the information presented by + <p>Erlang Top, <c>etop</c>, is a tool for presenting information + about Erlang processes similar to the information presented by <c>top</c> in UNIX. </p> </section> + <section> + <title>Getting Started</title> + <p>Start Erlang Top in either of the following ways:</p> + <list type="bulleted"> + <item>Use script <c>etop</c>.</item> + <item>Use batch file <c>etop.bat</c>, for example, + <c>etop -node tiger@durin</c>.</item> + </list> + </section> + <section> <title>Output</title> - <p>The output from <c>etop</c> can be graphical or text based. - </p> - <p>Text based it looks like this:</p> + <p>The output from Erlang Top is as follows:</p> <code type="none"><![CDATA[ ======================================================================================== tiger@durin 13:40:32 @@ -63,86 +72,63 @@ Pid Name or Initial Func Time Reds Memory MsgQ Current Func <127.137.0> net_kernel:do_spawn_ 0 553 5840 0 dbg:do_relay_1/1 ======================================================================================== ]]></code> - <p>And graphically it looks like this:</p> - <image file="etop_main.gif"> - <icaption>Graphical presentation of etop</icaption> - </image> <p>The header includes some system information: </p> <taglist> - <tag>Load</tag> - <item><c>cpu</c> is <c>Runtime/Wallclock</c>, i.e. the - percentage of time where the node has been - active, <c>procs</c> is the number of processes on the node, - and <c>runq</c> is the number of processes that are ready to - run.</item> - <tag>Memory</tag> - <item>This is the memory allocated by the node in kilo bytes.</item> + <tag><c>Load</c></tag> + <item> + <taglist> + <tag><c>cpu</c></tag> + <item><p><c>Runtime/Wallclock</c>, that is, the percentage of time + where the node has been active.</p></item> + <tag><c>procs</c></tag> + <item><p>The number of processes on the node.</p></item> + <tag><c>runq</c></tag> + <item><p>The number of processes that are ready to run.</p></item> + </taglist> + </item> + <tag><c>Memory</c></tag> + <item><p>The memory allocated by the node in kilobytes.</p></item> </taglist> <p>For each process the following information is presented: </p> <taglist> - <tag>Time</tag> - <item>This is the runtime for the process, i.e. the actual - time the process has been scheduled in.</item> - <tag>Reds</tag> - <item>This is the number of reductions that has been executed - on the process</item> - <tag>Memory</tag> - <item>This is the size of the process in bytes, obtained by a - call to <c>process_info(Pid,memory)</c>.</item> - <tag>MsgQ</tag> - <item>This is the length of the message queue for the process.</item> + <tag><c>Time</c></tag> + <item><p>The runtime for the process, that is, the time that the process + has been scheduled in.</p></item> + <tag><c>Reds</c></tag> + <item><p>The number of reductions executed on the process.</p></item> + <tag><c>Memory</c></tag> + <item><p>The size of the process in bytes, obtained by a + call to <c>process_info(Pid,memory)</c>.</p></item> + <tag><c>MsgQ</c></tag> + <item><p>The length of the message queue for the process.</p></item> </taglist> <note> <p><em>Time</em> and <em>Reds</em> can be presented as - accumulated values or as values since last update.</p> + accumulated values or as values since the last update.</p> </note> </section> - <section> - <title>Start</title> - <p>To start etop with the graphical presentation, use the script - <c>getop</c> or the batch file <c>getop.bat</c>, e.g. <c>getop -node tiger@durin</c></p> - <p>To start etop with the text based presentation use the script - <c>etop</c> or the batch file <c>etop.bat</c>, e.g. <c>etop -node tiger@durin</c>, - </p> - </section> - - <section> + <section> <title>Configuration</title> <p>All configuration parameters can be set at start by adding - <c>-OptName Value</c> to the command line, e.g. <c>etop -node tiger@durin -setcookie mycookie -lines 15</c>. - </p> - <p>The parameters <c>lines</c>, <c>interval</c>, <c>accumulate</c> - and <c>sort</c> can be changed during runtime. Use the - <em>Options</em> menu with the graphical presentation or the - function <c>etop:config/2</c> with the text based presentation. - </p> - <p>A list of all valid configuration parameters can be found in - the reference manual for <c>etop</c>. - </p> - <p>Note that it is even possible to change which information to - sort by by clicking the header line of the table in the graphical - presentation. + <c>-OptName Value</c> to the command line, for example:</p> + <pre> +% <input>etop -node tiger@durin -setcookie mycookie -lines 15</input></pre> + + <p>A list of all valid Erlang Top configuration parameters is available in + module <seealso marker="etop"><c>etop</c></seealso>. </p> - <section> - <title>Example: Change configuration with graphical presentation</title> - <image file="etop_opt.gif"> - <icaption>Select the option to change from the Options menu.</icaption> - </image> - <image file="etop_lines.gif"> - <icaption>Enter the new value in the popup window and click "Ok"</icaption> - </image> - <image file="etop_5.gif"> - <icaption>The interface is updated with the new configuration</icaption> - </image> - </section> - - <section> - <title>Example: Change configuration with text based presentation</title> - <code type="none"><![CDATA[ + <p>The parameters <c>lines</c>, <c>interval</c>, <c>accumulate</c>, + and <c>sort</c> can be changed during runtime with function + <seealso marker="etop#config/2"><c>etop:config/2</c></seealso>. + </p> + <p><em>Example:</em></p> + <p>Change configuration parameter <c>lines</c> with text-based presentation. + Before the change, 10 lines are presented as follows:</p> + <code type="none"><![CDATA[ ======================================================================================== tiger@durin 10:12:39 Load: cpu 0 Memory: total 1858 binary 33 @@ -162,8 +148,14 @@ Pid Name or Initial Func Time Reds Memory MsgQ Current Func <127.43.0> ddll_server 0 582 3744 0 gen_server:loop/6 <127.5.0> application_controll 0 569 6756 0 gen_server:loop/6 ======================================================================================== ]]></code> - <p><em><c>etop:config(lines,5).</c></em> <br></br> -<em><c>ok</c></em></p> + <p>Function <c>etop:config/2</c> is called to change the number of showed + lines to 5:</p> + + <pre> +> <input>etop:config(lines,5).</input> +ok</pre> + + <p>After the change, 5 lines are presented as follows:</p> <code type="none"><![CDATA[ (etop@durin)2> ======================================================================================== @@ -181,24 +173,21 @@ Pid Name or Initial Func Time Reds Memory MsgQ Current Func <127.43.0> ddll_server 0 0 3744 0 gen_server:loop/6 ======================================================================================== ]]></code> - </section> </section> <section> - <title>Print to file</title> - <p>At any time, the current <c>etop</c> display can be dumped to a - text file. Use <em>Dump to file</em> on the <em>File</em> menu - with the graphical presentation or the function <c>etop:dump/1</c> - with the text based presentation. + <title>Print to File</title> + <p>At any time, the current Erlang Top display can be dumped to a + text file with function + <seealso marker="etop#dump/1"><c>etop:dump/1</c></seealso>. </p> </section> <section> <title>Stop</title> - <p>To stop <c>etop</c>, use <em>Exit</em> on the <em>File</em> - menu for the graphical presentation, or the function - <c>etop:stop/0</c> with the text based presentation. - </p> + <p>To stop Erlang Top, use function + <seealso marker="etop#stop/0"><c>etop:stop/0</c></seealso>. + </p> </section> </chapter> diff --git a/lib/observer/doc/src/fascicules.xml b/lib/observer/doc/src/fascicules.xml index 0678195e07..37feca543f 100644 --- a/lib/observer/doc/src/fascicules.xml +++ b/lib/observer/doc/src/fascicules.xml @@ -1,4 +1,4 @@ -<?xml version="1.0" encoding="latin1" ?> +<?xml version="1.0" encoding="utf-8" ?> <!DOCTYPE fascicules SYSTEM "fascicules.dtd"> <fascicules> diff --git a/lib/observer/doc/src/introduction_ug.xml b/lib/observer/doc/src/introduction_ug.xml new file mode 100644 index 0000000000..21f0dc709f --- /dev/null +++ b/lib/observer/doc/src/introduction_ug.xml @@ -0,0 +1,49 @@ +<?xml version="1.0" encoding="utf-8" ?> +<!DOCTYPE chapter SYSTEM "chapter.dtd"> + +<chapter> + <header> + <copyright> + <year>2016</year><year>2016</year> + <holder>Ericsson AB. All Rights Reserved.</holder> + </copyright> + <legalnotice> + Licensed under the Apache License, Version 2.0 (the "License"); + you may not use this file except in compliance with the License. + You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an "AS IS" BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. + + </legalnotice> + + <title>Introduction</title> + <prepared></prepared> + <docno></docno> + <date></date> + <rev></rev> + <file>introduction_ug.xml</file> + </header> +<section> + <title>Scope</title> + <p>The Observer application is a container including the following + tools for tracing and investigation of distributed systems:</p> + <list type="bulleted"> + <item>Observer</item> + <item>Trace Tool Builder</item> + <item>Erlang Top</item> + <item>Crashdump Viewer</item> + </list> + </section> + + <section> + <title>Prerequisites</title> + <p>It is assumed that the reader is familiar with the Erlang + programming language.</p> + </section> +</chapter> diff --git a/lib/observer/doc/src/notes.xml b/lib/observer/doc/src/notes.xml index 34e87374a2..505d0dcc89 100644 --- a/lib/observer/doc/src/notes.xml +++ b/lib/observer/doc/src/notes.xml @@ -1,23 +1,24 @@ -<?xml version="1.0" encoding="latin1" ?> +<?xml version="1.0" encoding="utf-8" ?> <!DOCTYPE chapter SYSTEM "chapter.dtd"> <chapter> <header> <copyright> - <year>2004</year><year>2013</year> + <year>2004</year><year>2016</year> <holder>Ericsson AB. All Rights Reserved.</holder> </copyright> <legalnotice> - The contents of this file are subject to the Erlang Public License, - Version 1.1, (the "License"); you may not use this file except in - compliance with the License. You should have received a copy of the - Erlang Public License along with this software. If not, it can be - retrieved online at http://www.erlang.org/. - - Software distributed under the License is distributed on an "AS IS" - basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See - the License for the specific language governing rights and limitations - under the License. + Licensed under the Apache License, Version 2.0 (the "License"); + you may not use this file except in compliance with the License. + You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an "AS IS" BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. </legalnotice> @@ -31,6 +32,316 @@ <p>This document describes the changes made to the Observer application.</p> +<section><title>Observer 2.2</title> + + <section><title>Improvements and New Features</title> + <list> + <item> + <p> + Update observer GUI to support tracing on ports, and to + set matchspecs for send/receive. This required some minor + bugfixes in runtime_tools/dbg.</p> + <p> + Own Id: OTP-13481</p> + </item> + <item> + <p> + Update dbg and ttb to work with a tracer module as tracer + and tracing on ports.</p> + <p> + Own Id: OTP-13500</p> + </item> + <item> + <p> + Added possibility to change update frequency and length + of the graph windows.</p> + <p> + Own Id: OTP-13555</p> + </item> + <item> + <p> + Improved background coloring to work with dark themes and + other visual improvements.</p> + <p> + Own Id: OTP-13556</p> + </item> + <item> + <p> + Crashdump viewer now allows port info "Port controls + forker process..."</p> + <p> + Own Id: OTP-13647</p> + </item> + </list> + </section> + +</section> + +<section><title>Observer 2.1.2</title> + + <section><title>Improvements and New Features</title> + <list> + <item> + <p> + Documentation corrections.</p> + <p> + Own Id: OTP-12994</p> + </item> + </list> + </section> + +</section> + +<section><title>Observer 2.1.1</title> + + <section><title>Fixed Bugs and Malfunctions</title> + <list> + <item> + <p> + Show ets owner pid in crashdump viewers popup window, + thanks Leo Liu.</p> + <p> + Own Id: OTP-13030</p> + </item> + <item> + <p> + Several initialisms (eg, ERTS, ETS, SMP) are used as + headings. They were being capitalized incorrectly.</p> + <p> + Own Id: OTP-13044</p> + </item> + <item> + <p> + Fixed a crash in crashdump viewer when dump contained a + truncated binary.</p> + <p> + Own Id: OTP-13163</p> + </item> + </list> + </section> + +</section> + +<section><title>Observer 2.1</title> + + <section><title>Fixed Bugs and Malfunctions</title> + <list> + <item> + <p> + Show run queue status in crashdump viewer.</p> + <p> + Own Id: OTP-12401</p> + </item> + <item> + <p> + Don't refresh observer table view if there was no change</p> + <p> + Own Id: OTP-12819</p> + </item> + </list> + </section> + + + <section><title>Improvements and New Features</title> + <list> + <item> + <p> + Added display of new crashdump information available in + crashdumps from Erlang/OTP 18.</p> + <p> + Own Id: OTP-12363</p> + </item> + <item> + <p> + Added the possibility to view sasl log entries for + processes.</p> + <p> + Own Id: OTP-12504</p> + </item> + <item> + <p> + Add memory allocator usage and utilization graphs.</p> + <p> + Own Id: OTP-12631</p> + </item> + </list> + </section> + +</section> + +<section><title>Observer 2.0.4</title> + + <section><title>Fixed Bugs and Malfunctions</title> + <list> + <item> + <p> + Fix crash when opening a process information window.</p> + <p> + Own Id: OTP-12634</p> + </item> + </list> + </section> + +</section> + +<section><title>Observer 2.0.3</title> + + <section><title>Fixed Bugs and Malfunctions</title> + <list> + <item> + <p> + A note saying only R15B nodes can be observed is removed + from the user guide.</p> + <p> + Own Id: OTP-12078</p> + </item> + </list> + </section> + +</section> + +<section><title>Observer 2.0.2</title> + + <section><title>Fixed Bugs and Malfunctions</title> + <list> + <item> + <p> + Fixed statusbar on Windows</p> + <p> + Own Id: OTP-12162</p> + </item> + </list> + </section> + +</section> + +<section><title>Observer 2.0.1</title> + + <section><title>Fixed Bugs and Malfunctions</title> + <list> + <item> + <p> + crashdump_viewer would crash if the owner of a timer was + specified as the process' registered name. This has been + corrected.</p> + <p> + Own Id: OTP-11919</p> + </item> + <item> + <p> + Fix crash and minor updates.</p> + <p> + Own Id: OTP-11949</p> + </item> + </list> + </section> + +</section> + +<section><title>Observer 2.0</title> + + <section><title>Fixed Bugs and Malfunctions</title> + <list> + <item> + <p> + etop trace handler now works in smp environment (Thanks + to Péter Gömöri)</p> + <p> + Own Id: OTP-11633</p> + </item> + <item> + <p> + Application upgrade (appup) files are corrected for the + following applications: </p> + <p> + <c>asn1, common_test, compiler, crypto, debugger, + dialyzer, edoc, eldap, erl_docgen, et, eunit, gs, hipe, + inets, observer, odbc, os_mon, otp_mibs, parsetools, + percept, public_key, reltool, runtime_tools, ssh, + syntax_tools, test_server, tools, typer, webtool, wx, + xmerl</c></p> + <p> + A new test utility for testing appup files is added to + test_server. This is now used by most applications in + OTP.</p> + <p> + (Thanks to Tobias Schlager)</p> + <p> + Own Id: OTP-11744</p> + </item> + </list> + </section> + + + <section><title>Improvements and New Features</title> + <list> + <item> + <p> + Removed gs based applications and gs based backends. The + <c>observer</c> application replaces the removed + applications.</p> + <p> + *** POTENTIAL INCOMPATIBILITY ***</p> + <p> + Own Id: OTP-10915</p> + </item> + <item> + <p> + The <c>crashdump_viewer</c> is re-written using + <c>wx</c>. The old <c>webtool</c> interface for + <c>crashdump_viewer</c> does no longer exist.</p> + <p> + *** POTENTIAL INCOMPATIBILITY ***</p> + <p> + Own Id: OTP-11179</p> + </item> + </list> + </section> + +</section> + +<section><title>Observer 1.3.1.2</title> + + <section><title>Fixed Bugs and Malfunctions</title> + <list> + <item> + <p> + The documentation for <c>ttb:tracer/2</c> incorrectly + stated that there was an option named '<c>overload</c>', + while the correct name used in the implementation is + '<c>overload_check</c>'.</p> + <p> + Own Id: OTP-11335 Aux Id: seq12385 </p> + </item> + <item> + <p> + Fixed typo in observer documentation. Thanks to Dave + Parfitt.</p> + <p> + Own Id: OTP-11475</p> + </item> + </list> + </section> + +</section> + +<section><title>Observer 1.3.1.1</title> + + <section><title>Improvements and New Features</title> + <list> + <item> + <p> + The encoding of the <c>notes.xml</c> file has been + changed from latin1 to utf-8 to avoid future merge + problems.</p> + <p> + Own Id: OTP-11310</p> + </item> + </list> + </section> + +</section> + <section><title>Observer 1.3.1</title> <section><title>Fixed Bugs and Malfunctions</title> @@ -52,13 +363,12 @@ <section><title>Improvements and New Features</title> <list> <item> - <p> <list> <item> The new Memory field from a crash dump is now presented by crashdump viewer, both in the process overview and in the process detail page. </item> <item> A summary of blocks- and carriers sizes is added to the allocator information page in the crashdump viewer. - </item> </list></p> + </item> </list> <p> Own Id: OTP-10604 Aux Id: kunagi-336 [247] </p> </item> @@ -139,7 +449,7 @@ <p> Start position was lost after a 'Found' -> 'Not found' search sequence leading an undefined position in the next - search. Thanks to Peti G�mori</p> + search. Thanks to Peti Gömori</p> <p> Own Id: OTP-10218</p> </item> @@ -187,7 +497,6 @@ <item> <p> The following bugs in <c>ttb</c> have been corrected:</p> - <p> <list> <item><c>ttb:tracer/2</c> would earlier crash when trying to set up tracing for a diskless node to wrap files, i.e. when option @@ -200,7 +509,7 @@ <c>{file,{local,Filename}}</c></item> <item>A deadlock would sometimes occur due to an information printout from the <c>ttb_control</c> process when <c>ttb</c> was - stopped.</item> </list></p> + stopped.</item> </list> <p> Own Id: OTP-9431</p> </item> @@ -228,7 +537,6 @@ <item> <p> The following new features are added to <c>ttb</c>:</p> - <p> <list> <item>A one-command trace setup is added, <c>ttb:start_trace/4</c>.</item> <item>The following new options are added to <c>ttb:tracer/2</c>: <list> @@ -264,7 +572,7 @@ <c>disable_sort</c> is added to <c>ttb:format/2</c>. When this option is used, trace messages from different logs are not merged according to timestamps, but just appended - one log after the other. </item> </list></p> + one log after the other. </item> </list> <p> Own Id: OTP-9403</p> </item> @@ -272,7 +580,6 @@ <p> The following non backwards compatible changes are done in <c>ttb</c>:</p> - <p> <list> <item> When setting up trace with ttb, the 'timestamp' trace flag will now always be set. </item> <item> The 'fetch' option to ttb:stop/1 is removed since @@ -288,7 +595,7 @@ trace file, this is now changed so the handler state is passed not only from one trace message to the next in the same file, but also from one file to the next. </item> - </list></p> + </list> <p> *** POTENTIAL INCOMPATIBILITY ***</p> <p> diff --git a/lib/observer/doc/src/notes_history.xml b/lib/observer/doc/src/notes_history.xml index 2300983131..ef20a6dfa4 100644 --- a/lib/observer/doc/src/notes_history.xml +++ b/lib/observer/doc/src/notes_history.xml @@ -1,24 +1,25 @@ -<?xml version="1.0" encoding="latin1" ?> +<?xml version="1.0" encoding="utf-8" ?> <!DOCTYPE chapter SYSTEM "chapter.dtd"> <chapter> <header> <copyright> <year>2006</year> - <year>2011</year> + <year>2016</year> <holder>Ericsson AB, All Rights Reserved</holder> </copyright> <legalnotice> - The contents of this file are subject to the Erlang Public License, - Version 1.1, (the "License"); you may not use this file except in - compliance with the License. You should have received a copy of the - Erlang Public License along with this software. If not, it can be - retrieved online at http://www.erlang.org/. - - Software distributed under the License is distributed on an "AS IS" - basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See - the License for the specific language governing rights and limitations - under the License. + Licensed under the Apache License, Version 2.0 (the "License"); + you may not use this file except in compliance with the License. + You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an "AS IS" BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. The Initial Developer of the Original Code is Ericsson AB. </legalnotice> diff --git a/lib/observer/doc/src/observer.xml b/lib/observer/doc/src/observer.xml index 03830f2b1c..4d43ffe39f 100644 --- a/lib/observer/doc/src/observer.xml +++ b/lib/observer/doc/src/observer.xml @@ -1,23 +1,24 @@ -<?xml version="1.0" encoding="latin1" ?> +<?xml version="1.0" encoding="utf-8" ?> <!DOCTYPE erlref SYSTEM "erlref.dtd"> <erlref> <header> <copyright> - <year>2011</year> + <year>2011</year><year>2016</year> <holder>Ericsson AB, All Rights Reserved</holder> </copyright> <legalnotice> - The contents of this file are subject to the Erlang Public License, - Version 1.1, (the "License"); you may not use this file except in - compliance with the License. You should have received a copy of the - Erlang Public License along with this software. If not, it can be - retrieved online at http://www.erlang.org/. + Licensed under the Apache License, Version 2.0 (the "License"); + you may not use this file except in compliance with the License. + You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 - Software distributed under the License is distributed on an "AS IS" - basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See - the License for the specific language governing rights and limitations - under the License. + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an "AS IS" BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. The Initial Developer of the Original Code is Ericsson AB. </legalnotice> @@ -33,24 +34,25 @@ <file>observer.xml</file> </header> <module>observer</module> - <modulesummary>A GUI tool for observing an erlang system.</modulesummary> + <modulesummary>A GUI tool for observing an Erlang system.</modulesummary> <description> - <p>The observer is gui frontend containing various tools to - inspect a system. It displays system information, application - structures, process information, ets or mnesia tables and a frontend - for tracing with <seealso marker="ttb">ttb</seealso>. + <p>Observer is a graphical tool for observing the characteristics of + Erlang systems. The tool Observer displays system information, application + supervisor trees, process information, ETS tables, Mnesia tables, + and contains a front end for Erlang tracing with module + <seealso marker="ttb"><c>ttb</c></seealso>. </p> - <p>See the <seealso marker="observer_ug">user's guide</seealso> - for more information about how to get started.</p> + <p>For detalis about how to get started, see the + <seealso marker="observer_ug"><c>User's Guide</c></seealso>.</p> </description> <funcs> <func> <name>start() -> ok</name> - <fsummary>Start the observer gui</fsummary> + <fsummary>Start the Observer GUI.</fsummary> <desc> - <p>This function starts the <c>observer</c> gui. - Close the window to stop the application. + <p>Starts the Observer GUI. + To stop the tool, close the window. </p> </desc> </func> diff --git a/lib/observer/doc/src/observer_app.xml b/lib/observer/doc/src/observer_app.xml index e643568a39..a52d6cb4d9 100644 --- a/lib/observer/doc/src/observer_app.xml +++ b/lib/observer/doc/src/observer_app.xml @@ -1,29 +1,29 @@ -<?xml version="1.0" encoding="latin1" ?> +<?xml version="1.0" encoding="utf-8" ?> <!DOCTYPE appref SYSTEM "appref.dtd"> <appref> <header> <copyright> - <year>2002</year> - <year>2011</year> + <year>2002</year><year>2016</year> <holder>Ericsson AB, All Rights Reserved</holder> </copyright> <legalnotice> - The contents of this file are subject to the Erlang Public License, - Version 1.1, (the "License"); you may not use this file except in - compliance with the License. You should have received a copy of the - Erlang Public License along with this software. If not, it can be - retrieved online at http://www.erlang.org/. + Licensed under the Apache License, Version 2.0 (the "License"); + you may not use this file except in compliance with the License. + You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 - Software distributed under the License is distributed on an "AS IS" - basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See - the License for the specific language governing rights and limitations - under the License. + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an "AS IS" BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. The Initial Developer of the Original Code is Ericsson AB. </legalnotice> - <title>observer</title> + <title>Observer</title> <prepared>Siri Hansen</prepared> <responsible>Siri Hansen</responsible> <docno></docno> @@ -31,26 +31,21 @@ <checked></checked> <date>2002-04-08</date> <rev>PA1</rev> - <file>observer_app.sgml</file> + <file>observer_app.xml</file> </header> - <app>observer</app> + <app>Observer</app> <appsummary>The Observer Application</appsummary> <description> - <p>This chapter describes the <em>OBSERVER</em> application in - OTP, which provides tools for tracing and investigation of - distributed systems.</p> + <p>The Observer application contains tools for tracing and + investigation of distributed systems.</p> </description> <section> <title>Configuration</title> - <p>There are currently no configuration parameters available for + <p>No configuration parameters are available for this application. </p> </section> - <section> - <title>SEE ALSO</title> - <p></p> - </section> </appref> diff --git a/lib/observer/doc/src/observer_ug.xml b/lib/observer/doc/src/observer_ug.xml index 569d72e71e..6eb72f3e58 100644 --- a/lib/observer/doc/src/observer_ug.xml +++ b/lib/observer/doc/src/observer_ug.xml @@ -1,23 +1,24 @@ -<?xml version="1.0" encoding="latin1" ?> +<?xml version="1.0" encoding="utf-8" ?> <!DOCTYPE chapter SYSTEM "chapter.dtd"> <chapter> <header> <copyright> - <year>2011</year> + <year>2011</year><year>2016</year> <holder>Ericsson AB. All Rights Reserved.</holder> </copyright> <legalnotice> - The contents of this file are subject to the Erlang Public License, - Version 1.1, (the "License"); you may not use this file except in - compliance with the License. You should have received a copy of the - Erlang Public License along with this software. If not, it can be - retrieved online at http://www.erlang.org/. + Licensed under the Apache License, Version 2.0 (the "License"); + you may not use this file except in compliance with the License. + You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 - Software distributed under the License is distributed on an "AS IS" - basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See - the License for the specific language governing rights and limitations - under the License. + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an "AS IS" BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. </legalnotice> @@ -31,160 +32,322 @@ <section> <title>Introduction</title> - <p>Observer, is a graphical tool for observing the characteristics of - erlang systems. Observer displays system information, application - supervisor trees, process information, ets or mnesia tables and contains - a frontend for erlang tracing. + <p>Observer is a graphical tool for observing the characteristics of + Erlang systems. Observer displays system information, application + supervisor trees, process information, ETS tables, Mnesia tables + and contains a front end for Erlang tracing. </p> </section> <section> - <title>General</title> - <p>Normally observer should be run from a standalone node to minimize - the impact of the system being observed. Example: + <title>Getting Started</title> + <p>Run Observer from a standalone node to minimize the impact of the + system being observed. </p> - <code> - > erl -sname observer -hidden -setcookie MyCookie -run observer - </code> + <p><em>Example:</em></p> + <pre> +% <input>erl -sname observer -hidden -setcookie MyCookie -run observer</input></pre> <p> - Choose which node to observe via <c>Nodes</c> menu. The <c>View/Refresh - Interval</c> controls how frequent the view should be updated. + Select the node to observe with menu <em>Nodes</em>. + Menu <em>View > Refresh interval</em> controls how often + the view is to be updated. The refresh interval is set per viewer so you can have different settings for each viewer. To minimize the system - impact only the active viewer is updated and the other - views will be updated when activated. + impact, only the active viewer is updated. Other views are updated + when activated. </p> - <note> - <p>Only R15B nodes can be observed.</p> - </note> - <p> In general the mouse buttons behaves as expected, use left click - to select objects, right click to pop up a menu with most used - choices and double click to bring up information about the - selected object. In most viewers with several columns you can change - sort order by left clicking on column header. + <p>The mouse buttons behave as expected. Use left-click + to select objects, right-click to get a menu with the most used + options, and double-click to display information about the + selected object. In most viewers with many columns, you can change + the sort order by left-clicking the column header. </p> </section> <section> - <title>Applications</title> - <p>The <c>Applications</c> view lists application information. + <title>System Tab</title> + <p>Tab <em>System</em> displays general information about the active Erlang node + and its runtime system, such as build configuration, system capabilities, and + overall use statistics. +</p> + </section> + + <section> + <title>Load Charts Tab</title> + <p>Tab <em>Load Charts</em> displays graphs of the current resource use on + the active Erlang node.</p> + <p>Graph <c>Scheduler Utilization</c> shows scheduler use per scheduler, + where each scheduler use has a unique color.</p> + <p>Graph <c>Memory Usage</c> shows the total memory use and per memory category + use, where each category has a unique color. The categories are as + follows:</p> + <taglist> + <tag><c>Total</c></tag> + <item><p>The sum of all memory categories.</p></item> + <tag><c>Processes</c></tag> + <item><p>The sum of all process memory used.</p></item> + <tag><c>Atom</c></tag> + <item><p>The size used by the atom table.</p></item> + <tag><c>Binary</c></tag> + <item><p>The sum of all off-heap binaries allocated.</p></item> + <tag><c>Code</c></tag> + <item><p>The memory allocated for code storage.</p></item> + <tag><c>Ets</c></tag> + <item><p>The used memory for all ETS tables.</p></item> + </taglist> + + <p>Graph <c>IO Usage</c> shows the current I/O load on the system.</p> + </section> + + <section> + <title>Memory Allocators Tab</title> + <p>Tab <em>Memory Allocators</em> displays detailed information of the carrier + size and current memory carriers. For details about memory carriers, + see module + <seealso marker="erts:erts_alloc"><c>erts_alloc</c></seealso> + in application ERTS.</p> + </section> + + <section> + <title>Applications Tab</title> + <p>Tab <em>Applications</em> presents application information. Select an application in the left list to display its supervisor - tree. - </p> - <p><c>Trace process</c> will add the selected process identifier - to <c>Trace Overview</c> view and the node the process resides on - will be added as well. - </p> - <p><c>Trace named process</c> will add the - registered name of the process. This can be useful when tracing on - several nodes, then processes with that name will be traced on all traced - nodes. - </p> - <p><c>Trace process tree</c> and <c>Trace named process - tree</c> will add the selected process and all processes below, - right of, it to the <c>Trace Overview</c> view. + tree. The right-click options in the tree are as follows: </p> + <taglist> + <tag>Process info</tag> + <item><p>Opens a detailed information window on the selected process, + including the following:</p> + <taglist> + <tag>Process Information</tag> + <item><p>Shows the process information.</p></item> + <tag>Messages</tag> + <item><p>Shows the process messages.</p></item> + <tag>Dictionary</tag> + <item><p>Shows the process dictionary.</p></item> + <tag>Stack Trace</tag> + <item><p>Shows the process current stack trace.</p></item> + <tag>State</tag> + <item><p>Shows the process state.</p></item> + <tag>Log</tag> + <item><p>If enabled and available, shows the process SASL + log entries.</p></item> + </taglist> + </item> + <tag>Trace process</tag> + <item><p>Adds the selected process identifier to tab <em>Trace Overview</em> + plus the node that the process resides on.</p></item> + <tag>Trace named process</tag> + <item><p>Adds the registered name of the process. This can be useful when tracing on + many nodes, as processes with that name are then traced on all traced nodes.</p></item> + <tag>Trace process tree</tag> + <item><p>Adds the selected process and all processes below, + right of it, to tab <em>Trace Overview</em>.</p></item> + <tag>Trace named process tree</tag> + <item><p>Adds the selected process and all processes below, + right of it, to tab <em>Trace Overview</em>.</p></item> + </taglist> </section> <section> - <title>Processes</title> - <p>The <c>Processes</c> view lists process information. - For each process the following information is presented: + <title>Processes Tab</title> + <p>Tab <em>Processes</em> lists process information in columns. + For each process the following information is displayed: </p> <taglist> <tag>Pid</tag> - <item>The process identifier.</item> + <item><p>The process identifier.</p></item> <tag>Reds</tag> - <item>This is the number of reductions that has been executed - on the process</item> + <item><p>The number of reductions executed on the process. + This can be presented as accumulated values or as values since the last update.</p></item> <tag>Memory</tag> - <item>This is the size of the process in bytes, obtained by a - call to <c>process_info(Pid,memory)</c>.</item> + <item><p>The size of the process, in bytes, obtained by a + call to <c>process_info(Pid,memory)</c>.</p></item> <tag>MsgQ</tag> - <item>This is the length of the message queue for the process.</item> + <item><p>The length of the message queue for the process.</p></item> + </taglist> + + <p>Option <em>Process info</em> opens a detailed information window on the process under the mouse pointer, + including the following:</p> + <taglist> + <tag>Process Information</tag> + <item><p>Shows the process information.</p></item> + <tag>Messages</tag> + <item><p>Shows the process messages.</p></item> + <tag>Dictionary</tag> + <item><p>Shows the process dictionary.</p></item> + <tag>Stack Trace</tag> + <item><p>Shows the process current stack trace.</p></item> + <tag>State</tag> + <item><p>Shows the process state.</p></item> + <tag>Log</tag> + <item><p>If enabled and available, shows the process SASL log entries.</p></item> </taglist> + <note> - <p><em>Reds</em> can be presented as accumulated values or as values since last update.</p> + <p><em>Log</em> requires application SASL to be started on the observed node, + with <c>log_mf_h</c> as log handler. + The Observed node must be Erlang/OTP R16B02 or higher. + The <c>rb</c> server must not be started on the observed node when clicking menu + <em>Log > Toggle log view</em>. The <c>rb</c> server is stopped on the observed node + when exiting or changing the observed node. + </p> </note> - <p><c>Trace Processes</c> will add the selected process identifiers to the <c>Trace Overview</c> view and the - node the processes reside on will be added as well. - <c>Trace Named Processes</c> will add the registered name of processes. This can be useful - when tracing is done on several nodes, then processes with that name will be traced on all traced nodes. + + <p>Option <em>Trace selected processes</em> adds the selected process identifiers to tab + <em>Trace Overview</em> plus the node that the processes reside on. </p> + <p>Option <em>Trace selected processes by name</em> adds the registered name of the processes. This can be + useful when tracing is done on many nodes, as processes with that name are then traced on + all traced nodes.</p> + <p>Option <em>Kill process</em> brutally kills the processes under + the mouse pointer by sending an exit signal with + reason <c>kill</c>.</p> + </section> <section> - <title>Table Viewer</title> - <p>The <c>Table Viewer</c> view lists tables. By default ets tables - are visible and unreadable, private ets, tables and tables created by the OTP - applications are not visible. Use <c>View</c> menu to view "system" - ets tables, unreadable ets tables or mnesia tables. + <title>Ports Tab</title> + <p>Tab <em>Ports</em> lists port information in columns. + For each port the following information is displayed: </p> - <p>Double click to view the content of the table. Select table and activate <c>View/Table Information</c> - menu to view table information. + <taglist> + <tag>Id</tag> + <item><p>The port identifier.</p></item> + <tag>Connected</tag> + <item><p>The process identifier for the process that owns the + port.</p></item> + <tag>Name</tag> + <item><p>The registered name of the port, if any.</p></item> + <tag>Controls</tag> + <item><p>The name of the command set by <seealso marker="erts:erlang#open_port-2"><c>erlang:open_port/2</c></seealso>.</p></item> + <tag>Slot</tag> + <item><p>The internal index of the port.</p></item> + </taglist> + + <p>Option <em>Port info</em> opens a detailed information window + for the port under the mouse pointer. In addition to the + information above, it also shows links and monitors.</p> + + <p>Option <em>Trace selected ports</em> adds the selected port + identifiers, and the nodes that the ports reside on, + to tab <em>Trace Overview</em>.</p> + + <p>Option <em>Trace selected ports by name</em> adds the + registered name of the port to tab <em>Trace Overview</em>. This + can be useful when tracing is done on many nodes, as ports with + that name are then traced on all traced nodes.</p> + + <p>Option <em>Close</em> + executes <seealso marker="erts:erlang#port_close-1"><c>erlang:port_close/1</c></seealso> + on the port under the mouse pointer.</p> + + </section> + + <section> + <title>Table Viewer Tab</title> + <p>Tab <em>Table Viewer</em> lists tables. By default, ETS tables + are displayed whereas unreadable private ETS tables and tables created by OTP + applications are not diplayed. Use menu <em>View</em> to view "system" + ETS tables, unreadable ETS tables, or Mnesia tables. </p> - <p>In the table viewer you can regexp search for objects, edit and delete objects. + <p>Double-click to view the table content, or right-click and + select option <em>Show Table Content</em>. To view table + information, select the table and activate menu <em>View > + Table information</em>, or right-click and select option <em>Table + info</em>.</p> + <p>You can use <seealso marker="stdlib:re">regular + expressions</seealso> and search for objects, and edit or delete them. </p> </section> <section> - <title>Trace Overview</title> - <p>The <c>Trace Overview</c> view handles tracing. Tracing is done - by selecting which processes to be traced and how to trace - them. You can trace messages, function calls and events, where - events are process related events such as <c>spawn</c>, - <c>exit</c> and several others. - </p> - - <p>When you want to trace function calls, you also need to setup - <c>trace patterns</c>. Trace patterns selects the function calls - that will be traced. The number of traced function calls can be - further reduced with <c>match specifications</c>. Match - specifications can also be used to trigger additional information + <title>Trace Overview Tab</title> + <p>Tab <em>Trace Overview</em> handles tracing. Trace by selecting + the processes or ports to be traced and how to trace them. For + processes, you can trace messages, function calls, scheduling, + garbage collections, and process-related events such + as <c>spawn</c>, <c>exit</c>, and many others. For ports, you can + trace messages, scheduling and port-related events. + </p> + + <p>To trace function calls, you also need to set up + <em>trace patterns</em>. Trace patterns select the function calls + to be traced. The number of traced function calls can be + further reduced with <em>match specifications</em>. Match + specifications can also be used to trigger more information in the trace messages. </p> - <note><p>Trace patterns only applies to the traced processes.</p></note> + + <p>You can also set match specifications on messages. By default, + if tracing messages, all messages sent and/or received by the + process or port are traced. Match specifications can be used to + reduce the number of traced messages and/or to trigger more + information in the trace messages.</p> + + <note><p>Trace patterns only apply to the traced processes and + ports.</p></note> <p> - Processes are added from the <c>Applications</c> or <c>Processes</c> views. - A special <c>new</c> identifier, meaning all processes spawned after trace start, - can be added with the <c>Add 'new' Process</c> button. + Processes are added from the <em>Applications</em> + or <em>Processes</em> tabs. Ports are added from + the <em>Ports</em> tab. A special <em>new</em> identifier, + meaning all processes, or ports, started after trace start, can + be added with buttons <em>Add 'new' Processes</em> and <em>Add + 'new' Ports</em>, respecively. </p> <p> - When adding processes, a window with trace options will pop up. The chosen options will - be set for the selected processes. - Process options can be changed by right clicking on a process. + When adding processes or ports, a window with trace options is + displayed. The chosen options are set for the selected + processes/ports. To change the options, right-click the process + or port and select <em>Edit process options</em>. To remove a + process or port from the list, right-click and select <em>Remove + process</em> or <em>Remove port</em>, respectively. </p> <p> - Processes added by process identifiers will add the nodes these - processes resides on in the node list. Additional nodes can be added by the <c>Add - Nodes</c> button. + Processes and ports added by process/port identifiers add the + nodes these processes/ports reside on in the node list. More + nodes can be added by clicking button <em>Add Nodes</em>, or by + right-clicking in the <em>Nodes</em> list and select <em>Add + Nodes</em>. To remove nodes, select them, then right-click and + choose <em>Remove nodes</em>. + </p> + <p> + If function calls are traced, trace patterns must be added by clicking button + <em>Add Trace Pattern</em>. Select a module, function(s), and a match specification. + If no functions are selected, all functions in the module are traced.</p> + <p> + Trace patterns can also be added for traced messages. Click + button <em>Add Trace Pattern</em> and select <em>Messages + sent</em> or <em>Messages received</em>, and a match + specification. </p> <p> - If function calls are traced, trace patterns must be added by <c>Add Trace Pattern</c> button. - Select a module, function(s) and a match specification. - If no functions are selected, all functions in the module will be traced. A few basic match specifications are provided in the tool, and you can provide your own match specifications. The syntax of match - specifications are described in the <seealso - marker="erts:match_spec">ERTS User's Guide</seealso>. To simplify - the writing of a match specification they can also be written as - <c>fun/1</c> see <seealso marker="stdlib:ms_transform">ms_transform manual page</seealso> for - further information. - </p> - - <p>Use the <c>Start trace</c> button to start the trace. - By default trace output is written to a new window, tracing is stopped when the - window is closed, or with <c>Stop Trace</c> button. - Trace output can be changed via <c>Options/Output</c> menu. - The trace settings, including match specifications, can be saved to, or loaded from, a file. - </p> - <p>More information about tracing can be found in <seealso - marker="runtime_tools:dbg">dbg</seealso> and in the chapter "Match - specifications in Erlang" in <seealso marker="erts:match_spec">ERTS User's - Guide</seealso> and the - <seealso marker="stdlib:ms_transform">ms_transform manual page</seealso>. + specifications is described in the <seealso + marker="erts:match_spec"><c>ERTS User's Guide</c></seealso>. To simplify + the writing of a match specification, they can also be written as + <c>fun/1</c>. For details, see module + <seealso marker="stdlib:ms_transform">ms_transform</seealso> + in application STDLIB. + </p> + + <p>Click button <em>Start Trace</em> to start the trace. + By default, trace output is written to a new window. Tracing is stopped + when the window is closed, or when clicking button <em>Stop Trace</em>. + Trace output can be changed with menu <em>Options > Output</em>. + The trace settings, including match specifications, can be saved to, + or loaded from, a file. + </p> + <p>For details about tracing, see module <seealso + marker="runtime_tools:dbg">dbg</seealso> in application Runtime_Tools + and in section "Match specifications in Erlang" in + <seealso marker="erts:match_spec"><c>ERTS User's Guide</c></seealso> + and in module + <seealso marker="stdlib:ms_transform"><c>ms_transform</c></seealso> + in application STDLIB. </p> </section> </chapter> diff --git a/lib/observer/doc/src/part.xml b/lib/observer/doc/src/part.xml index 0d6aad09f2..165bd5864a 100644 --- a/lib/observer/doc/src/part.xml +++ b/lib/observer/doc/src/part.xml @@ -1,23 +1,24 @@ -<?xml version="1.0" encoding="latin1" ?> +<?xml version="1.0" encoding="utf-8" ?> <!DOCTYPE part SYSTEM "part.dtd"> <part xmlns:xi="http://www.w3.org/2001/XInclude"> <header> <copyright> - <year>2002</year><year>2011</year> + <year>2002</year><year>2016</year> <holder>Ericsson AB. All Rights Reserved.</holder> </copyright> <legalnotice> - The contents of this file are subject to the Erlang Public License, - Version 1.1, (the "License"); you may not use this file except in - compliance with the License. You should have received a copy of the - Erlang Public License along with this software. If not, it can be - retrieved online at http://www.erlang.org/. - - Software distributed under the License is distributed on an "AS IS" - basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See - the License for the specific language governing rights and limitations - under the License. + Licensed under the Apache License, Version 2.0 (the "License"); + you may not use this file except in compliance with the License. + You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an "AS IS" BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. </legalnotice> @@ -28,9 +29,8 @@ <rev></rev> </header> <description> - <p>The <em>Observer</em> application contains tools for tracing - and investigation of distributed systems.</p> </description> + <xi:include href="introduction_ug.xml"/> <xi:include href="observer_ug.xml"/> <xi:include href="ttb_ug.xml"/> <xi:include href="etop_ug.xml"/> diff --git a/lib/observer/doc/src/part_notes.xml b/lib/observer/doc/src/part_notes.xml index cd659395af..ba15c39cda 100644 --- a/lib/observer/doc/src/part_notes.xml +++ b/lib/observer/doc/src/part_notes.xml @@ -1,23 +1,24 @@ -<?xml version="1.0" encoding="latin1" ?> +<?xml version="1.0" encoding="utf-8" ?> <!DOCTYPE part SYSTEM "part.dtd"> <part xmlns:xi="http://www.w3.org/2001/XInclude"> <header> <copyright> - <year>2004</year><year>2009</year> + <year>2004</year><year>2016</year> <holder>Ericsson AB. All Rights Reserved.</holder> </copyright> <legalnotice> - The contents of this file are subject to the Erlang Public License, - Version 1.1, (the "License"); you may not use this file except in - compliance with the License. You should have received a copy of the - Erlang Public License along with this software. If not, it can be - retrieved online at http://www.erlang.org/. - - Software distributed under the License is distributed on an "AS IS" - basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See - the License for the specific language governing rights and limitations - under the License. + Licensed under the Apache License, Version 2.0 (the "License"); + you may not use this file except in compliance with the License. + You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an "AS IS" BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. </legalnotice> diff --git a/lib/observer/doc/src/part_notes_history.xml b/lib/observer/doc/src/part_notes_history.xml index 1ba0875fec..e60210924c 100644 --- a/lib/observer/doc/src/part_notes_history.xml +++ b/lib/observer/doc/src/part_notes_history.xml @@ -1,24 +1,25 @@ -<?xml version="1.0" encoding="latin1" ?> +<?xml version="1.0" encoding="utf-8" ?> <!DOCTYPE part SYSTEM "part.dtd"> <part> <header> <copyright> <year>2006</year> - <year>2011</year> + <year>2016</year> <holder>Ericsson AB, All Rights Reserved</holder> </copyright> <legalnotice> - The contents of this file are subject to the Erlang Public License, - Version 1.1, (the "License"); you may not use this file except in - compliance with the License. You should have received a copy of the - Erlang Public License along with this software. If not, it can be - retrieved online at http://www.erlang.org/. + Licensed under the Apache License, Version 2.0 (the "License"); + you may not use this file except in compliance with the License. + You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 - Software distributed under the License is distributed on an "AS IS" - basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See - the License for the specific language governing rights and limitations - under the License. + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an "AS IS" BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. The Initial Developer of the Original Code is Ericsson AB. </legalnotice> diff --git a/lib/observer/doc/src/ref_man.xml b/lib/observer/doc/src/ref_man.xml index c33ce74141..73e7e0053a 100644 --- a/lib/observer/doc/src/ref_man.xml +++ b/lib/observer/doc/src/ref_man.xml @@ -1,23 +1,24 @@ -<?xml version="1.0" encoding="latin1" ?> +<?xml version="1.0" encoding="utf-8" ?> <!DOCTYPE application SYSTEM "application.dtd"> <application xmlns:xi="http://www.w3.org/2001/XInclude"> <header> <copyright> - <year>2002</year><year>2011</year> + <year>2002</year><year>2016</year> <holder>Ericsson AB. All Rights Reserved.</holder> </copyright> <legalnotice> - The contents of this file are subject to the Erlang Public License, - Version 1.1, (the "License"); you may not use this file except in - compliance with the License. You should have received a copy of the - Erlang Public License along with this software. If not, it can be - retrieved online at http://www.erlang.org/. - - Software distributed under the License is distributed on an "AS IS" - basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See - the License for the specific language governing rights and limitations - under the License. + Licensed under the Apache License, Version 2.0 (the "License"); + you may not use this file except in compliance with the License. + You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an "AS IS" BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. </legalnotice> @@ -29,14 +30,12 @@ <file>application.sgml</file> </header> <description> - <p>The <em>Observer</em> application contains tools for tracing - and investigation of distributed systems.</p> - <br></br> - </description> + </description> <xi:include href="observer_app.xml"/> <xi:include href="observer.xml"/> <xi:include href="ttb.xml"/> <xi:include href="etop.xml"/> <xi:include href="crashdump.xml"/> + <xi:include href="cdv.xml"/> </application> diff --git a/lib/observer/doc/src/ttb.xml b/lib/observer/doc/src/ttb.xml index 4e63aecbf2..94ecef24b4 100644 --- a/lib/observer/doc/src/ttb.xml +++ b/lib/observer/doc/src/ttb.xml @@ -1,51 +1,51 @@ -<?xml version="1.0" encoding="latin1" ?> +<?xml version="1.0" encoding="utf-8" ?> <!DOCTYPE erlref SYSTEM "erlref.dtd"> <erlref> <header> <copyright> - <year>2002</year> - <year>2011</year> + <year>2002</year><year>2016</year> <holder>Ericsson AB, All Rights Reserved</holder> </copyright> <legalnotice> - The contents of this file are subject to the Erlang Public License, - Version 1.1, (the "License"); you may not use this file except in - compliance with the License. You should have received a copy of the - Erlang Public License along with this software. If not, it can be - retrieved online at http://www.erlang.org/. + Licensed under the Apache License, Version 2.0 (the "License"); + you may not use this file except in compliance with the License. + You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 - Software distributed under the License is distributed on an "AS IS" - basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See - the License for the specific language governing rights and limitations - under the License. + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an "AS IS" BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. The Initial Developer of the Original Code is Ericsson AB. </legalnotice> <title>ttb</title> - <prepared>Siri hansen</prepared> - <prepared>Bartlomiej Puzon</prepared> + <prepared>Siri Hansen, Bartlomiej Puzon</prepared> <responsible></responsible> <docno>1</docno> <approved></approved> <checked></checked> <date>2010-08-13</date> <rev>PA1</rev> - <file>ttb.sgml</file> + <file>ttb.xml</file> </header> <module>ttb</module> <modulesummary>A base for building trace tools for distributed systems.</modulesummary> <description> - <p>The Trace Tool Builder <c>ttb</c> is a base for building trace + <p>The Trace Tool Builder, <c>ttb</c>, is a base for building trace tools for distributed systems. </p> - <p>When using <c>ttb</c>, <c>dbg</c> shall not be used in parallel.</p> + <p>When using <c>ttb</c>, do not use module <c>dbg</c> in application + Runtime_Tools in parallel.</p> </description> <funcs> <func> <name>start_trace(Nodes, Patterns, FlagSpec, Opts) -> Result</name> - <fsummary>Start a trace port on each given node.</fsummary> + <fsummary>Start a trace port on each specified node.</fsummary> <type> <v>Result = see p/2</v> <v>Nodes = see tracer/2</v> @@ -57,56 +57,64 @@ </type> <desc> <p>This function is a shortcut allowing to start a trace with one command. Each - tuple in <c>Patterns</c> is converted to list which is in turn passed to - <c>ttb:tpl</c>. - The call:<code type="none"> -ttb:start_trace([Node, OtherNode], -[{mod, foo, []}, {mod, bar, 2}], -{all, call}, -[{file, File}, {handler,{fun myhandler/4, S}}])</code> - is equivalent to <code type="none"> -ttb:start_trace([Node, OtherNode], [{file, File}, {handler,{fun myhandler/4, S}}]), + tuple in <c>Patterns</c> is converted to a list, which in turn is passed to + <c>ttb:tpl/2,3,4</c>.</p> + <p>The call:</p> + <pre> +> <input>ttb:start_trace([Node, OtherNode], + [{mod, foo, []}, {mod, bar, 2}], + {all, call}, + [{file, File}, {handler,{fun myhandler/4, S}}]).</input></pre> + <p> is equivalent to:</p> + <pre> +> <input>ttb:start_trace([Node, OtherNode], + [{file, File}, {handler,{fun myhandler/4, S}}]), ttb:tpl(mod, foo, []), ttb:tpl(mod, bar, 2, []), -ttb:p(all, call)</code> - </p> +ttb:p(all, call).</input></pre> </desc> </func> + <func> <name>tracer() -> Result</name> - <fsummary>This is equivalent to tracer(node()).</fsummary> + <fsummary>Equivalent to tracer(node()).</fsummary> <desc> - <p>This is equivalent to <c>tracer(node())</c>.</p> + <p>Equivalent to <c>tracer(node())</c>.</p> </desc> </func> + <func> <name>tracer(Shortcut) -> Result</name> - <fsummary>Handy shortcuts for common tracing settings</fsummary> + <fsummary>Handy shortcuts for common tracing settings.</fsummary> <type> <v>Shortcut = shell | dbg</v> </type> <desc> + <p>Handy shortcuts for common tracing settings.</p> <p><c>shell</c> is equivalent to <c>tracer(node(),[{file, {local, "ttb"}}, shell])</c>.</p> <p><c>dbg</c> is equivalent to <c>tracer(node(),[{shell, only}])</c>.</p> </desc> </func> + <func> <name>tracer(Nodes) -> Result</name> - <fsummary>This is equivalent to tracer(Nodes,[]).</fsummary> + <fsummary>Equivalent to tracer(Nodes,[]).</fsummary> <desc> - <p>This is equivalent to <c>tracer(Nodes,[])</c>.</p> + <p>Equivalent to <c>tracer(Nodes,[])</c>.</p> </desc> </func> + <func> <name>tracer(Nodes,Opts) -> Result</name> - <fsummary>Start a trace port on each given node.</fsummary> + <fsummary>Start a trace port on each specified node.</fsummary> <type> <v>Result = {ok, ActivatedNodes} | {error,Reason}</v> <v>Nodes = atom() | [atom()] | all | existing | new</v> <v>Opts = Opt | [Opt]</v> <v>Opt = {file,Client} | {handler, FormatHandler} | {process_info,PI} | - shell | {shell, ShellSpec} | {timer, TimerSpec} | {overload, {MSec, Module, Function}} - | {flush, MSec} | resume | {resume, FetchTimeout}</v> + shell | {shell, ShellSpec} | {timer, TimerSpec} | + {overload_check, {MSec, Module, Function}} | + {flush, MSec} | resume | {resume, FetchTimeout}</v> <v>TimerSpec = MSec | {MSec, StopOpts}</v> <v>MSec = FetchTimeout = integer()</v> <v>Module = Function = atom() </v> @@ -120,193 +128,227 @@ ttb:p(all, call)</code> <v>ShellSpec = true | false | only</v> </type> <desc> - <p>This function starts a file trace port on all given nodes - and also points the system tracer for sequential tracing to + <p>Starts a file trace port on all specified nodes + and points the system tracer for sequential tracing to the same port. </p> - <p>The given <c>Filename</c> will be prefixed with the node - name. Default <c>Filename</c> is "ttb". - </p> - <p><c>File={wrap,Filename,Size,Count}</c> can be used if - the size of the trace logs must be limited. Default values are - <c>Size=128*1024</c> and <c>Count=8</c>. - </p> - <p>When tracing diskless nodes, <c>ttb</c> must be started + <p><em>Options:</em></p> + <taglist> + <tag><c>Filename</c></tag> + <item><p>The specified <c>Filename</c> is prefixed with the node name. + Default <c>Filename</c> is <c>ttb</c>.</p></item> + <tag><c>File={wrap,Filename,Size,Count}</c></tag> + <item><p>Can be used if the size of the trace logs must be limited. + Default values are + <c>Size=128*1024</c> and <c>Count=8</c>.</p></item> + <tag><c>Client</c></tag> + <item><p>When tracing diskless nodes, <c>ttb</c> must be started from an external "trace control node" with disk access, and <c>Client</c> must be <c>{local, File}</c>. All trace information is then sent to the trace control node where - it is written to file. - </p> - <p>The <c>process_info</c> option indicates if process - information should be collected. If <c>PI = true</c> (which is + it is written to file.</p></item> + <tag><c>process_info</c></tag> + <item><p>Indicates if process + information is to be collected. If <c>PI = true</c> (which is default), each process identifier <c>Pid</c> is replaced by a tuple <c>{Pid,ProcessInfo,Node}</c>, where <c>ProcessInfo</c> - is the process' registered name its globally registered name, - or its initial function. It is possible to turn off this - functionality by setting <c>PI = false</c>. - </p> - <p>The <c>{shell, ShellSpec}</c> option indicates that the trace messages should - be printed on the console as they are received by the tracing - process. This implies <c>{local, File}</c> trace client. If the ShellSpec - is <c>only</c> (instead of <c>true</c>), no trace logs are stored. - </p> - <p>The <c>shell</c> option is a shortcut for <c>{shell, true}</c>.</p> - <p>The <c>timer</c> option indicates that the trace should be + is the registered process name, its globally registered name, + or its initial function. To turn off this functionality, + set <c>PI = false</c>.</p></item> + <tag><c>{shell, ShellSpec}</c></tag> + <item><p>Indicates that trace messages are to be printed on the + console as they are received by the tracing process. This implies + trace client <c>{local, File}</c>. If <c>ShellSpec</c> + is <c>only</c> (instead of <c>true</c>), no trace logs are stored.</p></item> + <tag><c>shell</c></tag> + <item><p>Shortcut for <c>{shell, true}</c>.</p></item> + <tag><c>timer</c></tag> + <item><p>Indicates that the trace is to be automatically stopped after <c>MSec</c> milliseconds. <c>StopOpts</c> - are passed to <c>ttb:stop/2</c> command if specified (default is <c>[]</c>). - Note that the timing is approximate, as delays related to + are passed to command <c>ttb:stop/2</c> if specified (default is <c>[]</c>). + Notice that the timing is approximate, as delays related to network communication are always present. The timer starts after - <c>ttb:p/2</c> is issued, so you can set up your trace patterns before. - </p> - <p>The <c>overload</c> option allows to enable overload + <c>ttb:p/2</c> is issued, so you can set up your trace patterns before.</p></item> + <tag><c>overload_check</c></tag> + <item><p>Allows to enable overload checking on the nodes under trace. <c>Module:Function(check)</c> - is performed each <c>MSec</c> milliseconds. If the check returns - <c>true</c>, the tracing is disabled on a given node.<br/> - <c>Module:Function</c> should be able to handle at least three - atoms: <c>init</c>, <c>check</c> and <c>stop</c>. <c>init</c> and - <c>stop</c> give the user a possibility to initialize and clean - up the check environment.<br/> - When a node gets overloaded, it is not possible to issue <c>ttb:p</c> - nor any command from the <c>ttb:tp</c> family, as it would lead to + is performed each <c>MSec</c> millisecond. If the check returns + <c>true</c>, the tracing is disabled on a specified node.</p> + <p><c>Module:Function</c> must be able to handle at least three + atoms: <c>init</c>, <c>check</c>, and <c>stop</c>. <c>init</c> and + <c>stop</c> allows you to initialize and clean + up the check environment.</p> + <p>When a node gets overloaded, it is not possible to issue <c>ttb:p/2</c> + or any command from the <c>ttb:tp/2,3,4</c> family, as it would lead to inconsistent tracing state (different trace specifications on - different node). - </p> - <p>The <c>flush</c> option periodically flushes all file trace - port clients (see <c>dbg:flush_trace_port/1</c>). When enabled, - the buffers are freed each <c>MSec</c> milliseconds. This option is - not allowed with <c>{file, {local, File}}</c> tracing. - </p> - <p><c>{resume, FetchTimeout}</c> enables the autoresume feature. - Whenever enabled, remote nodes try to reconnect to the controlling node - in case they were restarted. The feature requires <c>runtime_tools</c> - application to be started (so it has to be present in the <c>.boot</c> - scripts if the traced nodes run with embedded erlang). If this is - not possible, resume may be performed manually by starting - <c>runtime_tools</c> remotely using <c>rpc:call/4</c>.<br/> - <c>ttb</c> tries to fetch all logs from a reconnecting node before - reinitializing the trace. This has to finish within FetchTimeout milliseconds - or is aborted<br/> - By default, autostart information is stored in a file called + different nodes).</p></item> + <tag><c>flush</c></tag> + <item><p>Periodically flushes all file trace + port clients (see + <seealso marker="runtime_tools:dbg#flush_trace_port/1"> + <c>dbg:flush_trace_port/1</c></seealso>). When enabled, + the buffers are freed each <c>MSec</c> millisecond. This option is + not allowed with <c>{file, {local, File}}</c> tracing.</p></item> + <tag><c>{resume, FetchTimeout}</c></tag> + <item><p>Enables the autoresume feature. + When enabled, remote nodes try to reconnect to the controlling node + if they are restarted. The feature requires application Runtime_Tools + to be started (so it has to be present in the <c>.boot</c> + scripts if the traced nodes run with embedded Erlang). If this is + not possible, resume can be performed manually by starting + <c>Runtime_Tools</c> remotely using + <seealso marker="kernel:rpc#call/4"><c>rpc:call/4</c></seealso>.</p> + <p><c>ttb</c> tries to fetch all logs from a reconnecting node before + reinitializing the trace. This must finish within <c>FetchTimeout</c> + milliseconds or is aborted.</p> + <p>By default, autostart information is stored in a file named <c>ttb_autostart.bin</c> on each node. If this is not desired - (i.e. on diskless nodes), a custom module to handle autostart + (for example, on diskless nodes), a custom module handling autostart information storage and retrieval can be provided by specifying - <c>ttb_autostart_module</c> environment variable for the <c>runtime_tools</c> - application. The module has to respond to the following API: - <taglist> + environment variable <c>ttb_autostart_module</c> for the application + Runtime_Tools. The module must respond to the following API:</p> + <taglist> <tag><c>write_config(Data) -> ok</c></tag> - <item>Store the provided data for further retrieval. It is + <item><p>Stores the provided data for further retrieval. It is important to realize that the data storage used must not - be affected by the node crash.</item> + be affected by the node crash.</p></item> <tag><c>read_config() -> {ok, Data} | {error, Error}</c></tag> - <item>Retrieve configuration stored with <c>write_config(Data)</c>.</item> + <item><p>Retrieves configuration stored with <c>write_config(Data)</c>.</p></item> <tag><c>delete_config() -> ok</c></tag> - <item>Delete configuration stored with <c>write_config(Data)</c>. - Note that after this call any subsequent calls to <c>read_config</c> - must return <c>{error, Error}</c>. + <item><p>Deletes configuration stored with <c>write_config(Data)</c>. + Notice that after this call any subsequent calls to <c>read_config</c> + must return <c>{error, Error}</c>.</p> </item> - </taglist> - </p> - <p>The <c>resume</c> option implies the default <c>FetchTimeout</c>, which is + </taglist> + <p><c>resume</c> implies the default <c>FetchTimeout</c>, which is 10 seconds</p> + </item> + </taglist> + </desc> </func> + <func> - <name>p(Procs,Flags) -> Return</name> - <fsummary>Sets the given trace flags on the given processes.</fsummary> + <name>p(Item,Flags) -> Return</name> + <fsummary>Set the specified trace flags on the specified processes or ports.</fsummary> <type> - <v>Return = {ok,[{Procs,MatchDesc}]}</v> - <v>Procs = Process | [Process] | all | new | existing</v> - <v>Process = pid() | atom() | {global,atom()}</v> + <v>Return = {ok,[{Item,MatchDesc}]}</v> + <v>Items = Item | [Item]</v> + <v>Item = pid() | port() | RegName | {global,GlobalRegName} | + all | processes | ports | + existing | existing_processes | existing_ports | + new | new_processes | new_ports</v> + <v>RegName = atom()</v> + <v>GlobalRegName = term()</v> <v>Flags = Flag | [Flag]</v> </type> <desc> - <p>This function sets the given trace flags on the given - processes. The <c>timestamp</c> flag is always turned on. + <p>Sets the specified trace flags on the specified processes + or ports. Flag <c>timestamp</c> is always turned on. </p> - <p>Please turn to the Reference manual for module <c>dbg</c> - for details about the possible trace flags. The parameter - <c>MatchDesc</c> is the same as returned from <c>dbg:p/2</c></p> - <p>Processes can be given as registered names, globally - registered names or process identifiers. If a registered name - is given, the flags are set on processes with this name on all - active nodes.</p> - <p>Issuing this command starts the timer for this trace if - <c>timer</c> option was specified with <c>tracer/2</c>. + <p>See the Reference Manual for module + <seealso marker="runtime_tools:dbg"><c>dbg</c></seealso> + for the possible trace flags. Parameter + <c>MatchDesc</c> is the same as returned from + <c>dbg:p/2</c>.</p> + <p>Processes can be specified as registered names, globally + registered names, or process identifiers. Ports can be + specified as registered names or port identifiers. If a + registered name is specified, the flags are set on + processes/ports with this name on all active nodes.</p> + <p>Issuing this command starts the timer for this trace if option + <c>timer</c> is specified with <c>tracer/2</c>. </p> </desc> </func> + <func> - <name>tp, tpl, ctp, ctpl, ctpg</name> + <name>tp, tpl, tpe, ctp, ctpl, ctpg, ctpe</name> <fsummary>Set and clear trace patterns.</fsummary> <desc> - <p>These functions should be used in combination with the - <c>call</c> trace flag for setting and clearing trace - patterns. When the <c>call</c> trace flag is set on a process, - function calls will be traced on that process if a trace - pattern has been set for the called function. Trace patterns - specifies how to trace a function by using match - specifications. Match specifications are described in the - User's Guide for the erlang runtime system <c>erts</c>. + <p>These functions are to be used with trace + flag <c>call</c>, <c>send</c>, and <c>'receive'</c> for + setting and clearing trace patterns.</p> + <p>When trace flag <c>call</c> is set on a process, + function calls are traced on that process if a trace + pattern is set for the called function.</p> + <p>The <c>send</c> and <c>'receive'</c> flags enable tracing + of all messages sent and received by the process/port. Trace + patterns set with <c>tpe</c> may limit traced messages based + on the message content, the sender, and/or the receiver.</p> + <p>Trace patterns specify how to trace a function or a message + by using match specifications. Match specifications are + described in the + <seealso marker="erts:match_spec"><c>ERTS User's Guide</c></seealso>. </p> <p>These functions are equivalent to the corresponding - functions in <c>dbg</c>, but all calls are stored in the - history. The history buffer makes it easy to create config - files so that the same trace environment can be setup several - times, e.g. if you want to compare two test runs. It also + functions in module + <seealso marker="runtime_tools:dbg">dbg</seealso>, + but all calls are stored in the + history. The history buffer makes it easy to create configuration + files; the same trace environment can be set up many + times, for example, to compare two test runs. It also reduces the amount of typing when using <c>ttb</c> from the - erlang shell. + Erlang shell. </p> <taglist> <tag><c>tp</c></tag> - <item>Set trace pattern on global function calls</item> + <item><p>Sets trace patterns on global function calls.</p></item> <tag><c>tpl</c></tag> - <item>Set trace pattern on local and global function calls</item> + <item><p>Sets trace patterns on local and global function calls.</p></item> + <tag><c>tpe</c></tag> + <item><p>Sets trace patterns on messages.</p></item> <tag><c>ctp</c></tag> - <item>Clear trace pattern on local and global function - calls</item> + <item><p>Clears trace patterns on local and global function + calls.</p></item> <tag><c>ctpl</c></tag> - <item>Clear trace pattern on local function calls</item> + <item><p>Clears trace patterns on local function calls.</p></item> <tag><c>ctpg</c></tag> - <item>Clear trace pattern on global function calls</item> + <item><p>Clears trace patterns on global function calls.</p></item> + <tag><c>ctpe</c></tag> + <item><p>Clears trace patterns on messages.</p></item> </taglist> - <p>With <c>tp</c> and <c>tpl</c> one of match specification shortcuts - may be used (example: <c>ttb:tp(foo_module, caller)</c>). The shortcuts are: - <taglist> + <p>With <c>tp</c> and <c>tpl</c>, one of the match specification shortcuts + can be used (for example, <c>ttb:tp(foo_module, caller)</c>).</p> + <p>The shortcuts are as follows:</p> + <list type="bulleted"> <item><c>return</c> - for <c>[{'_',[],[{return_trace}]}]</c> - (report the return value)</item> + (report the return value from a traced function)</item> <item><c>caller</c> - for <c>[{'_',[],[{message,{caller}}]}]</c> (report the calling function)</item> <item><c>{codestr, Str}</c> - for <c>dbg:fun2ms/1</c> arguments passed as strings (example: <c>"fun(_) -> return_trace() end"</c>) </item> - </taglist> - </p> + </list> </desc> </func> + <func> <name>list_history() -> History</name> - <fsummary>Returns all calls stored in history</fsummary> + <fsummary>Return all calls stored in history.</fsummary> <type> <v>History = [{N,Func,Args}]</v> </type> <desc> <p>All calls to <c>ttb</c> is stored in the history. This function returns the current content of the history. Any entry - can be re-executed with <c>run_history/1</c> or stored in a - config file with <c>write_config/2/3</c>.</p> + can be reexecuted with <c>run_history/1</c> or stored in a + configuration file with <c>write_config/2,3</c>.</p> </desc> </func> + <func> <name>run_history(N) -> ok | {error, Reason}</name> - <fsummary>Executes one entry of the history</fsummary> + <fsummary>Execute one entry of the history.</fsummary> <type> <v>N = integer() | [integer()]</v> </type> <desc> - <p>Executes the given entry or entries from the history - list. History can be listed with <c>list_history/0</c>.</p> + <p>Executes the specified entry or entries from the history + list. To list history, use <c>list_history/0</c>.</p> </desc> </func> + <func> <name>write_config(ConfigFile,Config)</name> <fsummary>Equivalent to write_config(ConfigFile,Config,[]).</fsummary> @@ -314,9 +356,10 @@ ttb:p(all, call)</code> <p>Equivalent to <c>write_config(ConfigFile,Config,[])</c>.</p> </desc> </func> + <func> <name>write_config(ConfigFile,Config,Opts) -> ok | {error,Reason}</name> - <fsummary>Creates a config file.</fsummary> + <fsummary>Create a configuration file.</fsummary> <type> <v>ConfigFile = string()</v> <v>Config = all | [integer()] | [{Mod,Func,Args}]</v> @@ -327,92 +370,97 @@ ttb:p(all, call)</code> <v>Opt = append</v> </type> <desc> - <p>This function creates or extends a config file which can be + <p>Creates or extends a configuration file, which can be used for restoring a specific configuration later. </p> - <p>The content of the config file can either be fetched from - the history or given directly as a list of + <p>The contents of the configuration file can either be fetched from + the history or specified directly as a list of <c>{Mod,Func,Args}</c>. </p> - <p>If the complete history is to be stored in the config file - <c>Config</c> should be <c>all</c>. If only a selected number - of entries from the history should be stored, <c>Config</c> - should be a list of integers pointing out the entries to be + <p>If the complete history is to be stored in the configuration file, + <c>Config</c> must be <c>all</c>. If only a selected number + of entries from the history are to be stored, <c>Config</c> + must be a list of integers pointing out the entries to be stored. </p> - <p>If <c>Opts</c> is not given or if it is <c>[]</c>, + <p>If <c>Opts</c> is not specified or if it is <c>[]</c>, <c>ConfigFile</c> is deleted and a new file is created. If - <c>Opts = [append]</c>, <c>ConfigFile</c> will not be deleted. - The new information will be appended at the end of the file.</p> + <c>Opts = [append]</c>, <c>ConfigFile</c> is not deleted. + The new information is appended at the end of the file.</p> </desc> </func> + <func> <name>run_config(ConfigFile) -> ok | {error,Reason}</name> - <fsummary>Executes all entries in a config file.</fsummary> + <fsummary>Execute all entries in a configuration file.</fsummary> <type> <v>ConfigFile = string()</v> </type> <desc> - <p>Executes all entries in the given config file. Note that the history - of the last trace is always available in the file named - <c>ttb_last_config</c>.</p> + <p>Executes all entries in the specified configuration file. + Notice that the history of the last trace is always available + in file <c>ttb_last_config</c>.</p> </desc> </func> + <func> <name>run_config(ConfigFile,NumList) -> ok | {error,Reason}</name> - <fsummary>Executes selected entries from a config file.</fsummary> + <fsummary>Execute selected entries from a configuration file.</fsummary> <type> <v>ConfigFile = string()</v> <v>NumList = [integer()]</v> </type> <desc> - <p>Executes selected entries from the given config + <p>Executes selected entries from the specified configuration file. <c>NumList</c> is a list of integers pointing out the entries to be executed. </p> - <p>The content of a config file can be listed with + <p>To list the contents of a configuration file, use <c>list_config/1</c>.</p> - <p> Note that the history - of the last trace is always available in the file named - <c>ttb_last_config</c>.</p> + <p>Notice that the history of the last trace is always available + in file <c>ttb_last_config</c>.</p> </desc> </func> + <func> <name>list_config(ConfigFile) -> Config | {error,Reason}</name> - <fsummary>Lists all entries in a config file.</fsummary> + <fsummary>List all entries in a configuration file.</fsummary> <type> <v>ConfigFile = string()</v> <v>Config = [{N,Func,Args}]</v> </type> <desc> - <p>Lists all entries in the given config file.</p> + <p>Lists all entries in the specified configuration file.</p> </desc> </func> + <func> <name>write_trace_info(Key,Info) -> ok</name> - <fsummary>Writes any information to the <c>.ti</c>file.</fsummary> + <fsummary>Write any information to file <c>.ti</c>.</fsummary> <type> <v>Key = term()</v> <v>Info = Data | fun() -> Data</v> <v>Data = term()</v> </type> <desc> - <p>The <c>.ti</c> file contains <c>{Key,ValueList}</c> - tuples. This function adds <c>Data</c> to the ValueList + <p>File <c>.ti</c> contains <c>{Key,ValueList}</c> + tuples. This function adds <c>Data</c> to the <c>ValueList</c> associated with <c>Key</c>. All information written with this - function will be included in the call to the format handler.</p> + function is included in the call to the format handler.</p> </desc> </func> + <func> <name>seq_trigger_ms() -> MatchSpec</name> - <fsummary>Equivalent to seq_trigger_ms(all)</fsummary> + <fsummary>Equivalent to seq_trigger_ms(all).</fsummary> <desc> - <p>Equivalent to <c>seq_trigger_ms(all)</c></p> + <p>Equivalent to <c>seq_trigger_ms(all)</c>.</p> </desc> </func> + <func> <name>seq_trigger_ms(Flags) -> MatchSpec</name> - <fsummary>Returns a match_spec() which starts sequential tracing</fsummary> + <fsummary>Return a match_spec() which starts sequential tracing.</fsummary> <type> <v>MatchSpec = match_spec()</v> <v>Flags = all | SeqTraceFlag | [SeqTraceFlag]</v> @@ -420,54 +468,55 @@ ttb:p(all, call)</code> </type> <desc> <p>A match specification can turn on or off sequential - tracing. This function returns a match specification which - turns on sequential tracing with the given <c>Flags</c>. + tracing. This function returns a match specification, which + turns on sequential tracing with the specified <c>Flags</c>. </p> - <p>This match specification can be given as the last argument - to <c>tp</c> or <c>tpl</c>. The activated <c>Item</c> will - then become a <em>trigger</em> for sequential tracing. This - means that if the item is called on a process with the - <c>call</c> trace flag set, the process will be "contaminated" - with the seq_trace token. + <p>This match specification can be specified as the last argument + to <c>tp</c> or <c>tpl</c>. The activated <c>Item</c> + then becomes a <em>trigger</em> for sequential tracing. This + means that if the item is called on a process with trace flag + <c>call</c> set, the process is "contaminated" + with token <c>seq_trace</c>. </p> <p>If <c>Flags = all</c>, all possible flags are set. </p> - <p>Please turn to the reference manual for the - <em><c>seq_trace</c></em> module in the <em><c>kernel</c></em> - application to see the possible values for - <c>SeqTraceFlag</c>. For a description of the match_spec() - syntax, please turn to the <em>User's guide</em> for the - runtime system (<em>erts</em>). The chapter <em>Match Specification in Erlang</em> explains the general match - specification "language". + <p>The possible values for <c>SeqTraceFlag</c> are available in + <seealso marker="kernel:seq_trace"><c>seq_trace</c></seealso>.</p> + <p>For a description of the <c>match_spec()</c> syntax, + see section + <seealso marker="erts:match_spec"><c>Match Specifications in Erlang</c></seealso> + in <c>ERTS</c>, which explains the general match specification "language". </p> <note> <p>The <em>system tracer</em> for sequential tracing is automatically initiated by <c>ttb</c> when a trace port is - started with <c>ttb:tracer/0/1/2</c>.</p> + started with <c>ttb:tracer/0,1,2</c>.</p> </note> - <p>Example of how to use the <c>seq_trigger_ms/0/1</c> function:</p> - <code type="none"> -(tiger@durin)5> ttb:tracer(). + <p>An example of how to use function <c>seq_trigger_ms/0,1</c> follows:</p> + <pre> +(tiger@durin)5> <input>ttb:tracer().</input> {ok,[tiger@durin]} -(tiger@durin)6> ttb:p(all,call). +(tiger@durin)6> <input>ttb:p(all,call).</input> {ok,{[all],[call]}} -(tiger@durin)7> ttb:tp(mod,func,ttb:seq_trigger_ms()). +(tiger@durin)7> <input>ttb:tp(mod,func,ttb:seq_trigger_ms()).</input> {ok,[{matched,1},{saved,1}]} -(tiger@durin)8> </code> - <p>Whenever <c>mod:func(...)</c> is called after this, the - seq_trace token will be set on the executing process.</p> +(tiger@durin)8></pre> + <p>Whenever <c>mod:func(...)</c> is called after this, + token <c>seq_trace</c> is set on the executing process.</p> </desc> </func> + <func> <name>stop()</name> - <fsummary>Equivalent to stop([])</fsummary> + <fsummary>Equivalent to stop([]).</fsummary> <desc> <p>Equivalent to <c>stop([])</c>.</p> </desc> </func> + <func> <name>stop(Opts) -> stopped | {stopped, Dir}</name> - <fsummary>Stop tracing and fetch/format logs from all nodes</fsummary> + <fsummary>Stop tracing and fetch/format logs from all nodes.</fsummary> <type> <v>Opts = Opt | [Opt]</v> <v>Opt = nofetch | {fetch_dir, Dir} | format | {format, FormatOpts} | return_fetch_dir</v> @@ -484,88 +533,103 @@ ttb:p(all, call)</code> form <c>yyyymmdd-hhmmss</c>. Even logs from nodes on the same machine as the trace control node are moved to this directory. The history list is saved to a file named <c>ttb_last_config</c> - for further reference (as it will be not longer accessible - through history and configuration management functions (like + for further reference (as it is no longer accessible + through history and configuration management functions, like <c>ttb:list_history/0</c>). </p> - <p>The <c>nofetch</c> option indicates that trace logs shall not be - collected after tracing is stopped. - </p> - <p>The <c>{fetch, Dir}</c> option allows to specify the directory + <p><em>Options:</em></p> + <taglist> + <tag><c>nofetch</c></tag> + <item><p>Indicates that trace logs are not to be + collected after tracing is stopped.</p></item> + <tag><c>{fetch, Dir}</c></tag> + <item><p>Allows specification of the directory to fetch the data to. If the directory already exists, an - error is thrown. - </p> - <p>The <c>format</c> option indicates that the trace logs - shall be formatted after tracing is stopped. All logs in the fetch directory will be merged. - You may use <c>{format, FormatOpts}</c> to pass additional - arguments to <c>format/2</c>.</p> - <p>The <c>return_fetch_dir</c> option indicates that the return value - should be <c>{stopped, Dir}</c> and not just <c>stopped</c>. - This implies <c>fetch</c>. - </p> + error is thrown.</p></item> + <tag><c>format</c></tag> + <item><p>Indicates the trace logs to be formatted after tracing + is stopped. All logs in the fetch directory are merged.</p></item> + <tag><c>return_fetch_dir</c></tag> + <item><p>Indicates the return value + to be <c>{stopped, Dir}</c> and not just <c>stopped</c>. + This implies <c>fetch</c>.</p></item> + </taglist> + </desc> </func> + <func> <name>get_et_handler()</name> - <fsummary>Returns <c>et</c> handler.</fsummary> + <fsummary>Return the <c>et</c> handler.</fsummary> <desc> - <p>The <c>et</c> handler returned by the function may be used with <c>format/2</c> - or <c>tracer/2</c>. Example: <c>ttb:format(Dir, [{handler, ttb:get_et_handler()}])</c>.</p> + <p>Returns the <c>et</c> handler, which can be used with <c>format/2</c> + or <c>tracer/2</c>.</p> + <p>Example: <c>ttb:format(Dir, [{handler, ttb:get_et_handler()}])</c>.</p> </desc> </func> + <func> <name>format(File)</name> - <fsummary>Same as <c>format(File,[])</c>.</fsummary> + <fsummary>Equivalent to <c>format(File,[])</c>.</fsummary> <desc> - <p>Same as <c>format(File,[])</c>.</p> + <p>Equivalent to <c>format(File,[])</c>.</p> </desc> </func> + <func> <name>format(File,Options) -> ok | {error, Reason}</name> - <fsummary>Format a binary trace log</fsummary> + <fsummary>Format a binary trace log.</fsummary> <type> <v>File = string() | [string()]</v> - <d>This can be the name of a binary log, a list of such logs or the name of a directory containing one or more binary logs.</d> + <d>This can be the name of a binary log, a list of such logs, + or the name of a directory containing one or more binary logs.</d> <v>Options = Opt | [Opt]</v> <v>Opt = {out,Out} | {handler,FormatHandler} | disable_sort</v> <v>Out = standard_io | string()</v> <v>FormatHandler = {Function, InitialState}</v> <v>Function = fun(Fd,Trace,TraceInfo,State) -> State</v> <v>Fd = standard_io | FileDescriptor</v> - <d>This is the file descriptor of the destination file <c>Out</c></d> + <d>File descriptor of the destination file <c>Out</c>.</d> <v>Trace = tuple()</v> - <d>This is the trace message. Please turn to the Reference manual for the <c>erlang</c>module for details.</d> + <d>The trace message. For details, see the Reference Manual for + module <c>erlang</c>.</d> <v>TraceInfo = [{Key,ValueList}]</v> - <d>This includes the keys <c>flags</c>, <c>client</c> and <c>node</c>, and if <c>handler</c> is given as option to the tracer function, this is also included. In addition all information written with the <c>write_trace_info/2</c>function is included. </d> + <d>Includes the keys <c>flags</c>, <c>client</c>, and <c>node</c>. + If <c>handler</c> is specified as option to the tracer function, this + is also included. Also, all information written with function + <c>write_trace_info/2</c> is included.</d> </type> <desc> - <p>Reads the given binary trace log(s). The logs are processed - in the order of their timestamp as long as <c>disable_sort</c> - option is not given. + <p>Reads the specified binary trace log(s). The logs are processed + in the order of their time stamps as long as option <c>disable_sort</c> + is not specified. </p> <p>If <c>FormatHandler = {Function,InitialState}</c>, - <c>Function</c> will be called for each trace message. If - <c>FormatHandler = get_et_handler()</c>, <c>et_viewer</c> in - the <em>Event Tracer</em> application (<c>et</c>) is used for presenting + <c>Function</c> is called for each trace message.</p> + <p>If <c>FormatHandler = get_et_handler()</c>, <c>et_viewer</c> in + application ET is used for presenting the trace log graphically. <c>ttb</c> provides a few different - filters which can be selected from the Filter menu in the - <c>et_viewer</c>. If <c>FormatHandler</c> is not given, a - default handler is used which presents each trace message as a - line of text. + filters that can be selected from menu <em>Filters and scaling</em> + in the <c>et_viewer</c>.</p> + <p>If <c>FormatHandler</c> is not specified, a + default handler is used presenting each trace message as a + text line. </p> - <p>The state returned from each call of <c>Function</c> is passed to the next call, - even if next call is to format a message from another log file. + <p>The state returned from each call of <c>Function</c> is passed to + the next call, even if the next call is to format a message from another + log file. </p> - <p>If <c>Out</c> is given, <c>FormatHandler</c> gets the + <p>If <c>Out</c> is specified, <c>FormatHandler</c> gets the file descriptor to <c>Out</c> as the first parameter. </p> - <p><c>Out</c> is ignored if <c>et</c> format handler is used. + <p><c>Out</c> is ignored if the <c>et</c> format handler is used. </p> - <p>Wrap logs can be formatted one by one or all in one go. To - format one of the wrap logs in a set, give the exact name of - the file. To format the whole set of wrap logs, give the name - with '*' instead of the wrap count. See examples in the - <c>ttb</c> User's Guide.</p> + <p>Wrap logs can be formatted one by one or all at once. To + format one of the wrap logs in a set, specify the exact file name. + To format the whole set of wrap logs, specify the name + with <c>*</c> instead of the wrap count. For examples, see the + <seealso marker="ttb_ug#format"><c>User's Guide</c></seealso>. + </p> </desc> </func> </funcs> diff --git a/lib/observer/doc/src/ttb_ug.xml b/lib/observer/doc/src/ttb_ug.xml index 08093a9451..34591ae8de 100644 --- a/lib/observer/doc/src/ttb_ug.xml +++ b/lib/observer/doc/src/ttb_ug.xml @@ -1,23 +1,24 @@ -<?xml version="1.0" encoding="latin1" ?> +<?xml version="1.0" encoding="utf-8" ?> <!DOCTYPE chapter SYSTEM "chapter.dtd"> <chapter> <header> <copyright> - <year>2002</year><year>2011</year> + <year>2002</year><year>2016</year> <holder>Ericsson AB. All Rights Reserved.</holder> </copyright> <legalnotice> - The contents of this file are subject to the Erlang Public License, - Version 1.1, (the "License"); you may not use this file except in - compliance with the License. You should have received a copy of the - Erlang Public License along with this software. If not, it can be - retrieved online at http://www.erlang.org/. - - Software distributed under the License is distributed on an "AS IS" - basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See - the License for the specific language governing rights and limitations - under the License. + Licensed under the Apache License, Version 2.0 (the "License"); + you may not use this file except in compliance with the License. + You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an "AS IS" BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. </legalnotice> @@ -31,78 +32,85 @@ <section> <title>Introduction</title> - <p>The Trace Tool Builder is a base for building trace tools for - single node or distributed erlang systems. It requires the - <c>runtime_tools</c> application to be available on the traced + <p>Trace Tool Builder is a base for building trace tools for + single node or distributed Erlang systems. It requires the + Runtime_Tools application to be available on the traced node. </p> - <p>The main features of the Trace Tool Builder are:</p> + <p>The following are the main features of Trace Tool Builder:</p> <list type="bulleted"> - <item>Start tracing to file ports on several nodes with one + <item>Start tracing to file ports on many nodes with one function call.</item> - <item>Write additional information to a trace information file, + <item>Write more information to a trace information file, which is read during formatting.</item> - <item>Restoring of previous configuration by maintaining a + <item>Restore previous configuration by maintaining a history buffer and handling configuration files.</item> - <item>Some simple support for sequential tracing.</item> - <item>Formatting of binary trace logs and merging of logs from + <item>Provide some simple support for sequential tracing.</item> + <item>Format binary trace logs and merge logs from multiple nodes.</item> </list> - <p>The intention of the Trace Tool Builder is to serve - as a base for tailor made trace tools, but you may use it directly - from the erlang shell (it may mimic <c>dbg</c> behaviour while - still providing useful additions like match specification shortcuts). - The application only - allows the use of file port tracer, so if you would like - to use other types of trace clients you will be better off - using <c>dbg</c> directly instead.</p> + <p>The intention of Trace Tool Builder is to serve + as a base for tailor-made trace tools, but it can also be used directly + from the Erlang shell (it can mimic <c>dbg</c> behaviour while + still providing useful additions, such as match specification shortcuts). + Trace Tool Builder only allows the use of file port tracer, so to use + other types of trace clients it is better to use <c>dbg</c> directly.</p> </section> <section> <title>Getting Started</title> - <p>The <c>ttb</c> module is the interface to all functions in the - Trace Tool Builder. To get started the least you need to do is to - start a tracer with <c>ttb:tracer/0/1/2</c>, and set the required - trace flags on the processes you want to trace with - <c>ttb:p/2</c>. Then, when the tracing is completed, you must stop - the tracer with <c>ttb:stop/0/1</c> and format the trace log with - <c>ttb:format/1/2</c> (as long as there is anything to format, of - course). - </p> - <p><c>ttb:tracer/0/1/2</c> opens a trace port on each node - that shall be traced. By default, trace messages are written - to binary files on remote nodes(the binary trace log). + <p>Module <c>ttb</c> is the interface to all functions in + Trace Tool Builder.</p> + <p>To get started, the least you need to do is to + start a tracer with + <seealso marker="ttb#tracer/0"><c>ttb:tracer/0,1,2</c></seealso>, + and set the required + trace flags on the processes you want to trace with + <seealso marker="ttb#p/2"><c>ttb:p/2</c></seealso>.</p> + <p>When the tracing is completed, stop the tracer with + <seealso marker="ttb#stop/0"><c>ttb:stop/0,1</c></seealso> + and format the trace log with + <seealso marker="ttb#format/1"><c>ttb:format/1,2</c></seealso> + (if there is anything to format). </p> - <p><c>ttb:p/2</c> specifies which processes shall be - traced. Trace flags given in this call specify what to trace on - each process. You can call this function several times if you like - different trace flags to be set on different processes. - </p> - <p>If you want to trace function calls (i.e. if you have the - <c>call</c> trace flag set on any of your processes), you must + <p><em>Useful functions:</em></p> + <taglist> + <tag><c>ttb:tracer/0,1,2</c></tag> + <item><p>Opens a trace port on each node to be traced. By default, + trace messages are written to binary files on remote nodes (the + binary trace log).</p></item> + <tag><c>ttb:p/2</c></tag> + <item><p>Specifies the processes to be traced. Trace flags specified + in this call specify what to trace on each process. This function can be + called many times if you like different trace flags to be set on different + processes.</p></item> + <tag><c>ttb:tp/2,3,4</c> or <c>ttb:tpl/2,3,4</c></tag> + <item><p>If you want to trace function calls (that is, if you have + trace flag <c>call</c> set on any process), you must also set trace patterns on the required function(s) with - <c>ttb:tp</c> or <c>ttb:tpl</c>. A function is only traced if it - has a trace pattern. The trace pattern specifies how to trace the + <seealso marker="ttb#/0"><c>ttb:tp/2,3,4</c></seealso> or + <seealso marker="ttb#/0"><c>ttb:tpl/2,3,4</c></seealso>. + A function is only traced + if it has a trace pattern. The trace pattern specifies how to trace the function by using match specifications. Match specifications are - described in the User's Guide for the erlang runtime system - <c>erts</c>. - </p> - <p><c>ttb:stop/0/1</c> stops tracing on all nodes, deletes all - trace patterns and flushes the trace port buffer. - </p> - <p><c>ttb:format/1/2</c> translates the binary trace logs into - something readable. By default <c>ttb</c> presents each trace - message as a line of text, but you can also write your own handler - to make more complex interpretations of the trace information. A - trace log can even be presented graphically via the Event Tracer - application. Note that if you give the <c>format</c> option to - <c>ttb:stop/1</c> the formatting is automatically done when - stopping <c>ttb</c>. - </p> - + described in the + <seealso marker="erts:users_guide">ERTS User's Guide</seealso>.</p></item> + <tag><c>ttb:stop/0,1</c></tag> + <item><p>Stops tracing on all nodes, deletes all trace patterns, and + flushes the trace port buffer.</p></item> + <tag><c>ttb:format/1/2</c></tag> + <item><p>Translates the binary trace logs into something readable. + By default, <c>ttb</c> presents each trace message as a line of text, + but you can also write your own handler to make more complex interpretations + of the trace information. A trace log can also be presented graphically + with application Event Tracer (ET).</p> + <p>If option <c>format</c> is specified to <c>ttb:stop/1</c>, the formatting + is automatically done when stopping <c>ttb</c>.</p></item> + </taglist> + <section> - <title>Example: Tracing the local node from the erlang shell</title> - <p>This small module is used in the example:</p> + <title>Tracing Local Node from Erlang Shell</title> + <p>The following small module is used in the subsequent example:</p> <code type="none"> -module(m). -export([f/0]). @@ -113,25 +121,25 @@ f() -> From ! {self(),Now} end. </code> <p>The following example shows the basic use of <c>ttb</c> from - the erlang shell. Default options are used both for starting the - tracer and for formatting (the custom fetch dir is however provided). - This gives a trace log named <c>Node-ttb</c> in the newly-created - directory, where <c>Node</c> is the name of the node. The + the Erlang shell. Default options are used both for starting the + tracer and for formatting (the custom fetch directory is however provided). + This gives a trace log named <c>Node-ttb</c> in the newly created + directory, where <c>Node</c> is the node name. The default handler prints the formatted trace messages in the - shell.</p> - <code type="none"><![CDATA[ + shell:</p> + <pre> (tiger@durin)47> %% First I spawn a process running my test function -(tiger@durin)47> Pid = spawn(m,f,[]). -<0.125.0> +(tiger@durin)47> <input>Pid = spawn(m,f,[]).</input> +<0.125.0> (tiger@durin)48> (tiger@durin)48> %% Then I start a tracer... -(tiger@durin)48> ttb:tracer(). +(tiger@durin)48> <input>ttb:tracer().</input> {ok,[tiger@durin]} (tiger@durin)49> (tiger@durin)49> %% and activate the new process for tracing (tiger@durin)49> %% function calls and sent messages. -(tiger@durin)49> ttb:p(Pid,[call,send]). -{ok,[{<0.125.0>,[{matched,tiger@durin,1}]}]} +(tiger@durin)49> <input>ttb:p(Pid,[call,send]).</input> +{ok,[{<0.125.0>,[{matched,tiger@durin,1}]}]} (tiger@durin)50> (tiger@durin)50> %% Here I set a trace pattern on erlang:now/0 (tiger@durin)50> %% The trace pattern is a simple match spec @@ -139,33 +147,33 @@ f() -> (tiger@durin)50> %% traced. Refer to the reference_manual for (tiger@durin)50> %% the full list of match spec shortcuts (tiger@durin)50> %% available. -(tiger@durin)51> ttb:tp(erlang,now,return). +(tiger@durin)51> <input>ttb:tp(erlang,now,return).</input> {ok,[{matched,tiger@durin,1},{saved,1}]} (tiger@durin)52> (tiger@durin)52> %% I run my test (i.e. send a message to (tiger@durin)52> %% my new process) -(tiger@durin)52> Pid ! self(). -<0.72.0> +(tiger@durin)52> <input>Pid ! self().</input> +<0.72.0> (tiger@durin)53> (tiger@durin)53> %% And then I have to stop ttb in order to flush (tiger@durin)53> %% the trace port buffer -(tiger@durin)53> ttb:stop([return, {fetch_dir, "fetch"}]). +(tiger@durin)53> <input>ttb:stop([return, {fetch_dir, "fetch"}]).</input> {stopped, "fetch"} (tiger@durin)54> (tiger@durin)54> %% Finally I format my trace log -(tiger@durin)54> ttb:format("fetch"). -({<0.125.0>,{m,f,0},tiger@durin}) call erlang:now() -({<0.125.0>,{m,f,0},tiger@durin}) returned from erlang:now/0 -> +(tiger@durin)54> <input>ttb:format("fetch").</input> +({<0.125.0>,{m,f,0},tiger@durin}) call erlang:now() +({<0.125.0>,{m,f,0},tiger@durin}) returned from erlang:now/0 -> {1031,133451,667611} -({<0.125.0>,{m,f,0},tiger@durin}) <0.72.0> ! -{<0.125.0>,{1031,133451,667611}} -ok ]]></code> +({<0.125.0>,{m,f,0},tiger@durin}) <0.72.0> ! +{<0.125.0>,{1031,133451,667611}} +ok</pre> </section> <section> - <title>Example: Build your own tool</title> - <p>This small example shows a simple tool for "debug tracing", - i.e. tracing of function calls with return values.</p> + <title>Build Your Own Tool</title> + <p>The following example shows a simple tool for "debug tracing", + that is, tracing of function calls with return values:</p> <code type="none"><![CDATA[ -module(mydebug). -export([start/0,trc/1,stop/0,format/1]). @@ -227,124 +235,127 @@ do_print(Out,{trace_ts,P,return_from,{M,F,A},R,Ts},N) -> "Return value :~p~n~n", [N,Ts,P,M,F,A,R]). ]]></code> <p>To distinguish trace logs produced with this tool from other - logs, the <c>file</c> option is used in <c>tracer/2</c>. The - logs will therefore be fetched to a directory named + logs, option <c>file</c> is used in + <seealso marker="ttb#tracer/2"><c>tracer/2</c></seealso>. The + logs are therefore fetched to a directory named <c>ttb_upload_debug_log-YYYYMMDD-HHMMSS</c> </p> - <p>By using the <c>handler</c> option when starting the tracer, + <p>By using option <c>handler</c> when starting the tracer, the information about how to format the file is stored in the trace information file (<c>.ti</c>). This is not necessary, as - it might be given at the time of formatting instead. It can - however be useful if you e.g. want to automatically format your - trace logs by using the <c>format</c> option in - <c>ttb:stop/1</c>. It also means that you don't need any - knowledge of the content of a binary log to be able to format it - the way it was intended. If the <c>handler</c> option is given - both when starting the tracer and when formatting, the one given - when formatting is used. + it can be specified when formatting instead. However, It can + be useful if you, for example, want to format trace logs automatically + using option <c>format</c> in <c>ttb:stop/1</c>. Also, you do not need + any knowledge of the content of a binary log to format it the way it + is intended. If option <c>handler</c> is specified both when starting + the tracer and when formatting, the one specified when formatting is used. </p> - <p>The <c>call</c> trace flag is set on all processes. This - means that any function activated with the <c>trc/1</c> command - will be traced on all existing and new processes. + <p>Trace flag <c>call</c> is set on all processes. This + means that any function activated with command <c>trc/1</c> + is traced on all existing and new processes. </p> </section> </section> <section> - <title>Running the Trace Tool Builder against a remote node</title> + <title>Running Trace Tool Builder against Remote Node</title> <p>The Observer application might not always be available on the - node that shall be traced (in the following called the "traced - node"). It is still possible to run the Trace Tool Builder from + node to be traced (in the following called the "traced + node"). However, Trace Tool Builder can still be run from another node (in the following called the "trace control node") as - long as + long as the following is fulfilled: </p> <list type="bulleted"> <item>The Observer application is available on the trace control node.</item> - <item>The Runtime Tools application is available on both the + <item>The Runtime_Tools application is available on both the trace control node and the traced node.</item> </list> - <p>If the Trace Tool Builder shall be used against a remote node, + <p>If Trace Tool Builder is to be used against a remote node, it is highly recommended to start the trace control node as <em>hidden</em>. This way it can connect to the traced node - without the traced node "seeing" it, i.e. if the <c>nodes()</c> - BIF is called on the traced node, the trace control node will not - show. To start a hidden node, add the <c>-hidden</c> option to the - <c>erl</c> command, e.g.</p> - <code type="none"> -% erl -sname trace_control -hidden </code> + without being "seen" by it, that is, if the <c>nodes()</c> + BIF is called on the traced node, the trace control node does not + show. To start a hidden node, add option <c>-hidden</c> to the + <c>erl</c> command, for example:</p> + <pre> +% <input>erl -sname trace_control -hidden</input></pre> <section> - <title>Diskless node</title> + <title>Diskless Node</title> <p>If the traced node is diskless, <c>ttb</c> must be started from - a trace control node with disk access, and the <c>file</c> option - must be given to the <c>tracer/2</c> function with the value - <c>{local, File}</c>, e.g.</p> - <code type="none"> -(trace_control@durin)1> ttb:tracer(mynode@diskless,{file,{local, -{wrap,"mytrace"}}}). -{ok,[mynode@diskless]} </code> + a trace control node with disk access, and option <c>file</c> + must be specified to function <c>tracer/2</c> with value + <c>{local, File}</c>, for example:</p> + <pre> +(trace_control@durin)1> <input>ttb:tracer(mynode@diskless, + {file,{local,{wrap,"mytrace"}}}).</input> +{ok,[mynode@diskless]}</pre> </section> </section> <section> - <title>Additional tracing options</title> - <p>When setting up a trace, several features may be turned on:</p> + <title>More Tracing Options</title> + <p>When setting up a trace, the following features can also be activated:</p> <list type="bulleted"> - <item>time-constrained tracing,</item> - <item>overload protection,</item> - <item>autoresuming.</item> + <item>Time-constrained tracing</item> + <item>Overload protection</item> + <item>Autoresume</item> + <item><c>dbg</c> mode</item> </list> <section> - <title>Time-constrained tracing</title> - <p>Sometimes, it may be helpful to enable trace for a - given period of time (i.e. to monitor a system for 24 hours - or half of a second). This may be done by issuing additional - <c>{timer, TimerSpec}</c> option. If <c>TimerSpec</c> has the + <title>Time-Constrained Tracing</title> + <p>It can sometimes be helpful to enable trace for a + specified period of time (for example, to monitor a system for 24 hours + or half a second). This can be done with option + <c>{timer, TimerSpec}</c>. If <c>TimerSpec</c> has the form of <c>MSec</c>, the trace is stopped after <c>MSec</c> - milliseconds using <c>ttb:stop/0</c>. If any additional options - are provided (<c>TimerSpec = {MSec, Opts}</c>), <c>ttb:stop/1</c> - is called instead with <c>Opts</c> as the arguments. The timer - is started with <c>ttb:p/2</c>, so any trace patterns should - be set up before. <c>ttb:start_trace/4</c> - always sets up all pattern before invoking <c>ttb:p/2</c>. - Note that due to network and processing delays the the period - of tracing is approximate. - The example below shows how to set up a trace which will be - automatically stopped and formatted after 5 seconds - </p><code> -(tiger@durin)1>ttb:start_trace([node()], - [{erlang, now,[]}], - {all, call}, - [{timer, {5000, format}}]). -</code> + milliseconds using + <seealso marker="ttb#stop/0"><c>ttb:stop/0</c></seealso>. If more + options are provided (<c>TimerSpec = {MSec, Opts}</c>), + <seealso marker="ttb#stop/1"><c>ttb:stop/1</c></seealso> + is called instead with <c>Opts</c> as argument.</p> + <p>The timer is started with + <seealso marker="ttb#p/2"><c>ttb:p/2</c></seealso>, so any trace patterns + must be set up in advance. + <seealso marker="ttb#start_trace/4"><c>ttb:start_trace/4</c></seealso> + always sets up all patterns before invoking <c>ttb:p/2</c>.</p> + <p>The following example shows how to set up a trace that is + automatically stopped and formatted after 5 seconds: + </p><pre> +(tiger@durin)1> <input>ttb:start_trace([node()], + [{erlang, now,[]}], + {all, call}, + [{timer, {5000, format}}]).</input></pre> + <note><p>Because of network and processing delays, the period + of tracing is approximate.</p></note> + </section> <section> - <label>Overload protection</label> - <p>When tracing live systems, special care needs to be always taken - not to overload a node with too heavy tracing. <c>ttb</c> provides - the <c>overload</c> option to help to address the problem.</p> - <p><c>{overload, MSec, Module, Function}</c> instructs the ttb backend - (called <c>observer_backend</c>, part of the <c>runtime_tools</c> - application) to perform overload check every <c>MSec</c> milliseconds. - If the check (namely <c>Module:Function(check)</c>) returns + <title>Overload Protection</title> + <p>When tracing live systems, always take special care to not + overload a node with too heavy tracing. <c>ttb</c> provides + option <c>overload</c> to address this problem.</p> + <p><c>{overload, MSec, Module, Function}</c> instructs the <c>ttb</c> back end + (a part of the <seealso marker="runtime_tools:index">Runtime_Tools</seealso> + application) to perform overload check every <c>MSec</c> millisecond. + If the check (named <c>Module:Function(check)</c>) returns <c>true</c>, tracing is disabled on the selected node.</p> <p>Overload protection activated on one node does not affect other nodes, where the tracing continues as normal. - <c>ttb:stop/0/1</c> fetches data from all clients, including everything - that has been collected before overload protection was activated. - Note that - changing trace details (with <c>ttb:p</c> and <c>ttb:tp/tpl...</c>) - once overload protection gets activated in one of the traced - nodes is not permitted in order not to allow trace setup - to be inconsistent between nodes. - </p> - <p><c>Module:Function</c> provided with the <c>overload</c> option must - handle three calls: <c>init</c>, <c>check</c> and <c>stop</c>. <c>init</c> - and <c>stop</c> allows to perform some setup and teardown required by - the check. An overload check module could look like this (note that - <c>check</c> is always called by the same process, so <c>put</c> and - <c>get</c> are possible). - </p><code> + <c>ttb:stop/0,1</c> fetches data from all clients, including everything + collected before the activation of overload protection.</p> + + <note><p> + It is not allowed to change trace details + (with <c>ttb:p</c> and <c>ttb:tp/tpl...</c>) once overload + protection is activated in one of the traced nodes. This is to + avoid trace setup being inconsistent between nodes.</p></note> + + <p><c>Module:Function</c> provided with option <c>overload</c> must + handle three calls: <c>init</c>, <c>check</c>, and <c>stop</c>. <c>init</c> + and <c>stop</c> allow some setup and teardown required by + the check. An overload check module can look as follows: + </p><code type="none"> -module(overload). -export([check/1]). @@ -361,33 +372,37 @@ check(check) -> end; check(stop) -> get(pid) ! stop.</code> + <note><p> + <c>check</c> is always called by the same process, so <c>put</c> and + <c>get</c> are possible.</p></note> </section> <section> <title>Autoresume</title> - <p>It is possible that a node (probably a buggy one, hence traced) - crashes. In order to automatically resume tracing on the node - as soon as it gets back, <c>resume</c> has to be used. When - it is, the failing node tries to reconnect - to trace control node as soon as <c>runtime tools</c> is started. - This implies that <c>runtime_tools</c> must be included in - other node's startup chain (if it is not, one could still - resume tracing by starting <c>runtime_tools</c> manually, - i.e. by an RPC call).</p> - <p>In order not to loose the data that the failing node stored - up to the point of crash, the control node will try to fetch - it before restarting trace. This must happen within the allowed - time frame or is aborted (default is 10 seconds, can be customized with - <c>{resume, MSec}</c>). The data fetched this way is then - merged with all other traces.</p> - <p>Autostart feature requires additional data to be stored on + <p>A node can crash (probably a buggy one, hence traced). + Use <c>resume</c> to resume tracing on the node automatically + when it gets back. The failing node then tries to reconnect + to trace control node when <c>Runtime_Tools</c> is started. + This implies that <c>Runtime_Tools</c> must be included in + the startup chain of other nodes (if not, you can still + resume tracing by starting <c>Runtime_Tools</c> manually, + that is, by an RPC call).</p> + <p>To not lose the data that the failing node stored + up to the point of crash, the control node tries to fetch + it before restarting trace. This must occur within the allowed + time frame, otherwise it is aborted (default is 10 seconds, but it + can be changed with <c>{resume, MSec}</c>). The data fetched + this way is then merged with all other traces.</p> + <p>The autostart feature requires more data to be stored on traced nodes. By default, the data is stored automatically - to the file called "ttb_autostart.bin" in the traced node's cwd. - Users may decide to change this behaviour (i.e. on diskless + to the file named "ttb_autostart.bin" in the currect working directory + (cwd) of the traced node. + Users can change this behaviour (that is, on diskless nodes) by specifying their own module to handle autostart data storage and retrieval (<c>ttb_autostart_module</c> - environment variable of <c>runtime_tools</c>). Please see the - ttb's reference manual to see the module's API. This example - shows the default handler</p> + environment variable of <c>runtime_tools</c>). For information + about the API, see module + <seealso marker="ttb"><c>ttb</c></seealso>. + The following example shows the default handler:</p> <code> -module(ttb_autostart). -export([read_config/0, @@ -406,54 +421,60 @@ read_config() -> end. write_config(Data) -> - file:write_file(?AUTOSTART_FILENAME, term_to_binary(Data)). - </code> - <p>Remember that file trace ports buffer the data + file:write_file(?AUTOSTART_FILENAME, term_to_binary(Data)).</code> + + <note><p>Remember that file trace ports buffer the data by default. If the node crashes, trace messages are not - flushed to the binary log. If the chance of failure is - high, it might be a good idea to automatically flush - the buffers every now and then. Passing <c>{flush, MSec}</c> - as one of <c>ttb:tracer/2</c> option flushes all buffers - every <c>MSec</c> milliseconds.</p> + flushed to the binary log. If the risk of failure is + high, it can be a good idea to flush the buffers every + now and then automatically. Passing <c>{flush, MSec}</c> + as an option of <c>ttb:tracer/2</c> flushes all buffers + every <c>MSec</c> millisecond.</p></note> </section> <section> - <title>dbg mode</title> - <p>The <c>{shell, ShellType}</c> option allows to make <c>ttb</c> - operation similar to <c>dbg</c>. Using <c>{shell, true}</c> + <title>dbg Mode</title> + <p>Option <c>{shell, ShellType}</c> allows making <c>ttb</c> + operation similar to + <seealso marker="runtime_tools:dbg"><c>dbg</c></seealso>. + Using <c>{shell, true}</c> displays all trace messages in the shell before storing them. <c>{shell, only}</c> additionally disables message storage - (so that the tool behaves exactly like dbg). This is allowed - only with ip trace ports (<c>{trace, {local, File}}</c>). + (making the tool to behave exactly like <c>dbg</c>). This is + allowed only with IP trace ports (<c>{trace, {local, File}}</c>). </p> - <p>The command <c>ttb:tracer(dbg)</c> is a shortcut for the pure-dbg - mode (<c>{shell, only}</c>).</p> + <p>Command <c>ttb:tracer(dbg)</c> is a shortcut for the pure + <c>dbg</c> mode (<c>{shell, only}</c>).</p> </section> </section> <section> <marker id="trace_info"></marker> - <title>Trace Information and the .ti File</title> - <p>In addition to the trace log file(s), a file with the extension - <c>.ti</c> is created when the Trace Tool Builder is started. This - is the trace information file. It is a binary file, and it + <title>Trace Information and File .ti</title> + <p>In addition to the trace log file(s), a file with extension + <c>.ti</c> is created when Trace Tool Builder is started. This + is the trace information file. It is a binary file, which contains the process information, trace flags used, the name of - the node to which it belongs and all information written with the - <c>write_trace_info/2</c> function. .ti files are always fetched - with other logs when the trace is stopped. + the node to which it belongs, and all information written with + function + <seealso marker="ttb#write_trace_info/2"><c>ttb:write_trace_info/2</c></seealso>. + <c>.ti</c> files are always fetched with other logs when the trace is stopped. </p> <p>Except for the process information, everything in the trace information file is passed on to the handler function when - formatting. The <c>TI</c> parameter is a list of + formatting. Parameter <c>TI</c> is a list of <c>{Key,ValueList}</c> tuples. The keys <c>flags</c>, - <c>handler</c>, <c>file</c> and <c>node</c> are used for + <c>handler</c>, <c>file</c>, and <c>node</c> are used for information written directly by <c>ttb</c>. </p> - <p>You can add information to the trace information file by - calling <c>write_trace_info/2</c>. Note that <c>ValueList</c> - always will be a list, and if you call <c>write_trace_info/2</c> - several times with the same <c>Key</c>, the <c>ValueList</c> will - be extended with a new value each time. Example: + <p>Information to the trace information file by + can be added by calling + <seealso marker="ttb#write_trace_info/2"><c>ttb:write_trace_info/2</c></seealso>. + Notice that <c>ValueList</c> + always is a list, and if you call <c>write_trace_info/2</c> + many times with the same <c>Key</c>, the <c>ValueList</c> is + extended with a new value each time. </p> + <p><em>Example:</em></p> <p><c>ttb:write_trace_info(mykey,1)</c> gives the entry <c>{mykey,[1]}</c> in <c>TI</c>. Another call, <c>ttb:write_trace_info(mykey,2)</c>, changes this entry to @@ -466,15 +487,15 @@ write_config(Data) -> <p>If you want to limit the size of the trace logs, you can use wrap logs. This works almost like a circular buffer. You can specify the maximum number of binary logs and the maximum size of - each log. <c>ttb</c> will create a new binary log each time a log - reaches the maximum size. When the the maximum number of logs are + each log. <c>ttb</c> then creates a new binary log each time a log + reaches the maximum size. When the maximum number of logs are reached, the oldest log is deleted before a new one is created. </p> - <p>Note that the overall size of data generated by ttb may be greater - than the wrap specification would suggest - if a traced node restarts - and autoresume is enabled, old wrap log is always stored and + <note><p>The overall size of data generated by <c>ttb</c> can be greater + than the wrap specification suggests. If a traced node restarts + and autoresume is enabled, the old wrap log is always stored and a new one is created. - </p> + </p></note> <p>Wrap logs can be formatted one by one or all at once. See <seealso marker="#format">Formatting</seealso>. </p> @@ -484,52 +505,61 @@ write_config(Data) -> <marker id="format"></marker> <title>Formatting</title> <p>Formatting can be done automatically when stopping <c>ttb</c> - (see <seealso marker="#fetch_format">Automatically collect and format logs from all nodes</seealso>), or explicitly by calling - the <c>ttb:format/1/2</c> function. + (see section + <seealso marker="#fetch_format">Automatically Collect and Format Logs from All Nodes</seealso>), or explicitly by calling function + <c>ttb:format/1,2</c>. </p> <p>Formatting means to read a binary log and present it in a readable format. You can use the default format handler in <c>ttb</c> to present each trace message as a line of text, or write your own handler to make more complex interpretations of the - trace information. You can even use the Event Tracer <c>et</c> to - present the trace log graphically (see <seealso marker="#et_viewer">Presenting trace logs with Event Tracer</seealso>). + trace information. You can also use application ET to + present the trace log graphically (see section + <seealso marker="#et_viewer">Presenting Trace Logs with Event Tracer</seealso>). </p> - <p>The first argument to <c>ttb:format/1/2</c> specifies which + <p>The first argument to <c>ttb:format/1,2</c> specifies which binary log(s) to format. This is usually the name of a directory - that ttb created during log fetch. Unless there is the <c>disable_sort</c> - option provided, the logs from different files are always sorted - according to timestamp in traces. + that <c>ttb</c> created during log fetch. Unless option + <c>disable_sort</c> is provided, the logs from different files + are always sorted according to time-stamp in traces. </p> <p>The second argument to <c>ttb:format/2</c> is a list of - options. The <c>out</c> option specifies the destination where the - formatted text shall be written. Default destination is - <c>standard_io</c>, but a filename can also be given. The - <c>handler</c> option specifies the format handler to use. If this - option is not given, the <c>handler</c> option given when starting - the tracer is used. If the <c>handler</c> option was not given - when starting the tracer either, a default handler is used, which - prints each trace message as a line of text. The <c>disable_sort</c> - option indicates that there logs should not be merged according to - timestamp, but processed one file after another (this might be - a bit faster). + options as follows: </p> - <p>A format handler is a fun taking four arguments. This fun will - be called for each trace message in the binary log(s). A simple - example which only prints each trace message could be like this:</p> + <taglist> + <tag><c>out</c></tag> + <item><p>Specifies the destination to write the formatted text. + Default destination is <c>standard_io</c>, but a filename can + also be specified.</p></item> + <tag><c>handler</c></tag> + <item><p>Specifies the format handler to use. If this option is + not specified, option <c>handler</c> that is specified when starting + the tracer is used. If option <c>handler</c> is not specified + when starting the tracer either, a default handler is used, which + prints each trace message as a text line.</p></item> + <tag><c>disable_sort</c></tag> + <item><p>Indicates that the logs are not to be merged according to + time-stamp, but processed one file after another (this can be + a bit faster).</p></item> + </taglist> + <p>A format handler is a fun taking four arguments. This fun is + called for each trace message in the binary log(s). A simple + example that only prints each trace message can be as follows:</p> <code type="none"> fun(Fd, Trace, _TraceInfo, State) -> io:format(Fd, "Trace: ~p~n", [Trace]), State end. </code> - <p><c>Fd</c> is the file descriptor for the destination file, or + <p>Here, <c>Fd</c> is the file descriptor for the destination file, or the atom <c>standard_io</c>. <c>_TraceInfo</c> contains information - from the trace information file (see <seealso marker="#trace_info">Trace Information and the .ti File</seealso>). <c>State</c> is a state variable for the format - handler fun. The initial value of the <c>State</c> variable is - given with the handler option, e.g.</p> + from the trace information file (see section + <seealso marker="#trace_info">Trace Information and File .ti</seealso>). <c>State</c> is a state variable for the format + handler fun. The initial value of variable <c>State</c> is + specified with the handler option, for example:</p> <code type="none"> ttb:format("tiger@durin-ttb", [{handler, {{Mod,Fun}, initial_state}}]) ^^^^^^^^^^^^^ </code> - <p>Another format handler could be used to calculate time spent by + <p>Another format handler can be used to calculate the time spent by the garbage collector:</p> <code type="none"> fun(_Fd,{trace_ts,P,gc_start,_Info,StartTs},_TraceInfo,State) -> @@ -540,111 +570,118 @@ fun(_Fd,{trace_ts,P,gc_start,_Info,StartTs},_TraceInfo,State) -> io:format("GC in process ~w: ~w milliseconds~n", [P,Time]), State -- [{P,StartTs}] end </code> - <p>A more refined version of this format handler is the function - <c>handle_gc/4</c> in the module <c>multitrace.erl</c> which can - be found in the <c>src</c> directory of the Observer application. + <p>A more refined version of this format handler is function + <c>handle_gc/4</c> in module <c>multitrace.erl</c> + included in directory <c>src</c> of the Observer application. </p> - <p>The actual trace message is passed as the second argument (<c>Trace</c>). - The possible values of <c>Trace</c> are:</p> + <p>The trace message is passed as the second argument (<c>Trace</c>). + The possible values of <c>Trace</c> are the following:</p> <list type="bulleted"> - <item>all trace messages described in <c>erlang:trace/3</c> documentation, + <item>All trace messages described in + <seealso marker="erts:erlang#trace/3"><c>erlang:trace/3</c></seealso> </item> - <item><c>{drop, N}</c> if ip tracer is used (see <c>dbg:trace_port/2</c>), + <item><c>{drop, N}</c> if IP tracer is used (see + <seealso marker="runtime_tools:dbg#trace_port/2"><c>dbg:trace_port/2</c></seealso>) </item> - <item><c>end_of_trace</c> received once when all trace messages have - been processed.</item> + <item><c>end_of_trace</c> received once when all trace messages are + processed</item> </list> - <p>By giving the format handler <c>ttb:get_et_handler()</c>, you can have the trace - log presented graphically with <c>et_viewer</c> in the Event - Tracer application (see <seealso marker="#et_viewer">Presenting trace logs with Event Tracer</seealso>). + <p>By giving the format handler + <seealso marker="ttb#get_et_handler/0"><c>ttb:get_et_handler()</c></seealso>, + you can have the trace + log presented graphically with <c>et_viewer</c> in the ET + application (see section + <seealso marker="#et_viewer">Presenting Trace Logs with Event Tracer</seealso>). </p> - <p>You may always decide not to format the whole trace data contained - in the fetch directory, but analyze single files instead. In order - to do so, a single file (or list of files) have to be passed as - the first argument to <c>format/1/2</c>.</p> - <p>Wrap logs can be formatted one by one or all in one go. To - format one of the wrap logs in a set, give the exact name of the - file. To format the whole set of wrap logs, give the name with '*' - instead of the wrap count. An example: + <p>You can always decide not to format the whole trace data contained + in the fetch directory, but analyze single files instead. To do so, + a single file (or list of files) must be passed as the first argument + to <c>format/1,2</c>.</p> + <p>Wrap logs can be formatted one by one or all at once. To + format one of the wrap logs in a set, specify the exact file name. + To format the whole set of wrap logs, specify the name with <c>*</c> + instead of the wrap count. </p> + <p><em>Example:</em></p> <p>Start tracing:</p> - <code type="none"> -(tiger@durin)1> ttb:tracer(node(),{file,{wrap,"trace"}}). + <pre> +(tiger@durin)1> <input>ttb:tracer(node(),{file,{wrap,"trace"}}).</input> {ok,[tiger@durin]} -(tiger@durin)2> ttb:p(...) -... </code> - <p>This will give a set of binary logs, like:</p> +(tiger@durin)2> <input>ttb:p(...)</input> +...</pre> + <p>This gives a set of binary logs, for example:</p> <code type="none"> ... </code> <p>Format the whole set of logs:</p> - <code type="none"> -1> ttb:format("tiger@durin-trace.*.wrp"). + <pre> +1> <input>ttb:format("tiger@durin-trace.*.wrp").</input> .... ok -2> </code> +2> </pre> <p>Format only the first log:</p> - <code type="none"> -1> ttb:format("[email protected]"). + <pre> +1> <input>ttb:format("[email protected]").</input> .... ok -2> </code> +2> </pre> <p>To merge all wrap logs from two nodes:</p> - <code type="none"> -1> ttb:format(["tiger@durin-trace.*.wrp","lion@durin-trace.*.wrp"]). + <pre> +1> <input>ttb:format(["tiger@durin-trace.*.wrp","lion@durin-trace.*.wrp"]).</input> .... ok -2> </code> +2> </pre> <section> <marker id="et_viewer"></marker> - <title>Presenting trace logs with Event Tracer</title> - <p>For detailed information about the Event Tracer, please turn - to the User's Guide and Reference Manuals for the <c>et</c> - application. + <title>Presenting Trace Logs with Event Tracer</title> + <p>For detailed information about the Event Tracer, see the + <seealso marker="et:users_guide">ET</seealso> application. </p> - <p>By giving the format handler <c>ttb:get_et_handler()</c>, you can have the - trace log presented graphically with <c>et_viewer</c> in the - Event Tracer application. <c>ttb</c> provides a few different - filters which can be selected from the Filter menu in the - <c>et_viewer</c> window. The filters are names according to the - type of actors they present (i.e. what each vertical line in the - sequence diagram represent). Interaction between actors is shown - as red arrows between two vertical lines, and activities within - an actor are shown as blue text to the right of the actors line. + <p>By giving the format handler + <seealso marker="ttb#get_et_handler/0"><c>ttb:get_et_handler()</c></seealso>, + you can have the trace log presented graphically with + <c>et_viewer</c> in the ET application. + <c>ttb</c> provides filters that can be selected from the + menu <em>Filter</em> in the <c>et_viewer</c> window. The filters + are names according to the type of actors they present + (that is, what each vertical line in the sequence diagram represents). + Interaction between actors is shown as red arrows between two + vertical lines, and activities within an actor are shown as + blue text to the right of the actors line. </p> - <p>The <c>processes</c> filter is the only filter which will - show all trace messages from a trace log. Each vertical line in + <p>The <c>processes</c> filter is the only filter showing all + trace messages from a trace log. Each vertical line in the sequence diagram represents a process. Erlang messages, - spawn and link/unlink are typical interactions between - processes. Function calls, scheduling and garbage collection are - typical activities within a process. <c>processes</c> is the - default filter. + spawn, and link/unlink are typical interactions between + processes. Function calls, scheduling, and garbage collection, + are typical activities within a process. <c>processes</c> is + the default filter. </p> - <p>The rest of the filters will only show function calls and + <p>The remaining filters only show function calls and function returns. All other trace message are discarded. To get - the most out of these filters, <c>et_viewer</c> needs to known + the most out of these filters, <c>et_viewer</c> must know the caller of each function and the time of return. This can be - obtained by using both the <c>call</c> and <c>return_to</c> - flags when tracing. Note that the <c>return_to</c> flag only - works with local call trace, i.e. when trace patterns are set + obtained using both the <c>call</c> and <c>return_to</c> + flags when tracing. Notice that flag <c>return_to</c> only + works with local call trace, that is, when trace patterns are set with <c>ttb:tpl</c>. </p> - <p>The same result can be obtained by using the <c>call</c> flag - only and setting a match specification like this on local or - global function calls:</p> - <code type="none"> -1> dbg:fun2ms(fun(_) -> return_trace(),message(caller()) end). -[{'_',[],[{return_trace},{message,{caller}}]}] </code> - <p>This should however be done with care, since the - <c>{return_trace}</c> function in the match specification will - destroy tail recursiveness. + <p>The same result can be obtained by using the flag <c>call</c> + only and setting a match specification on local or + global function calls as follows:</p> + <pre> +1> <input>dbg:fun2ms(fun(_) -> return_trace(),message(caller()) end).</input> +[{'_',[],[{return_trace},{message,{caller}}]}]</pre> + <p>This must however be done with care, as function + <c>{return_trace}</c> in the match specification + destroys tail recursiveness. </p> <p>The <c>modules</c> filter shows each module as a vertical line in the sequence diagram. External function calls/returns - are shown as interactions between modules and internal function + are shown as interactions between modules, and internal function calls/returns are shown as activities within a module. </p> <p>The <c>functions</c> filter shows each function as a vertical @@ -655,9 +692,9 @@ ok <p>The <c>mods_and_procs</c> and <c>funcs_and_procs</c> filters are equivalent to the <c>modules</c> and <c>functions</c> filters respectively, except that each module or function can - have several vertical lines, one for each process it resides on. + have many vertical lines, one for each process it resides on. </p> - <p>In the next example, modules <c>foo</c> and <c>bar</c> are used:</p> + <p>In the following example, modules <c>foo</c> and <c>bar</c> are used:</p> <code type="none"> -module(foo). -export([start/0,go/0]). @@ -672,8 +709,9 @@ go() -> go -> bar:f1(), go() - end. -</code><code type="none"> + end.</code> + +<code type="none"> -module(bar). -export([f1/0,f3/0]). f1() -> @@ -684,57 +722,56 @@ f2() -> f3() -> ok.</code> - <p>Now let's set up the trace.</p> -<code> -(tiger@durin)1>%%First we retrieve the Pid to limit traced processes set -(tiger@durin)1>Pid = foo:start(). -(tiger@durin)2>%%Now we set up tracing -(tiger@durin)2>ttb:tracer(). -(tiger@durin)3>ttb:p(Pid, [call, return_to, procs, set_on_spawn]). -(tiger@durin)4>ttb:tpl(bar, []). -(tiger@durin)5>%%Invoke our test function and see output with et viewer -(tiger@durin)5>Pid ! go. -(tiger@durin)6>ttb:stop({format, {handler, ttb:get_et_handler()}}). -</code> - - <p>This shoud render a result similar to the - following: + <p>Setting up the trace:</p> +<pre> +(tiger@durin)1> %%First we retrieve the Pid to limit traced processes set +(tiger@durin)1> <input>Pid = foo:start().</input> +(tiger@durin)2> %%Now we set up tracing +(tiger@durin)2> <input>ttb:tracer().</input> +(tiger@durin)3> <input>ttb:p(Pid, [call, return_to, procs, set_on_spawn]).</input> +(tiger@durin)4> <input>ttb:tpl(bar, []).</input> +(tiger@durin)5> %%Invoke our test function and see output with et viewer +(tiger@durin)5> <input>Pid ! go.</input> +(tiger@durin)6> <input>ttb:stop({format, {handler, ttb:get_et_handler()}}).</input></pre> + + <p>This renders a result similar to the following: </p> - <p></p> <image file="et_processes.gif"> <icaption>Filter: "processes"</icaption> </image> + <p></p> <image file="et_modsprocs.gif"> <icaption>Filter: "mods_and_procs"</icaption> </image> - <p>Note, that we can use <c>ttb:start_trace/4</c> function to help - us here:</p> -<code> -(tiger@durin)1>Pid = foo:start(). -(tiger@durin)2>ttb:start_trace([node()], - [{bar,[]}], - {Pid, [call, return_to, procs, set_on_spawn]} - {handler, ttb:get_et_handler()}). -(tiger@durin)3>Pid ! go. -(tiger@durin)4>ttb:stop(format). -</code> + <p>Notice that function + <seealso marker="ttb#start_trace/4"><c>ttb:start_trace/4</c></seealso> + can be used as help as follows:</p> +<pre> +(tiger@durin)1> <input>Pid = foo:start().</input> +(tiger@durin)2> <input>ttb:start_trace([node()], + [{bar,[]}], + {Pid, [call, return_to, procs, set_on_spawn]} + {handler, ttb:get_et_handler()}).</input> +(tiger@durin)3> <input>Pid ! go.</input> +(tiger@durin)4> <input>ttb:stop(format).</input></pre> </section> </section> <section> <marker id="fetch_format"></marker> - <title>Automatically collect and format logs from all nodes</title> - <p>By default <c>ttb:stop/1</c> fetches trace logs and - trace information files from all nodes. The logs are stored in a - new directory named <c>ttb_upload-Filename-Timestamp</c> under the working - directory of the trace control node. Fetching may be disabled by - providing the <c>nofetch</c> option to <c>ttb:stop/1</c>. User can - specify a fetch directory of his choice passing the - <c>{fetch_dir, Dir}</c> option. + <title>Automatically Collect and Format Logs from All Nodes</title> + <p>By default, + + <seealso marker="ttb#stop/1"><c>ttb:stop/1</c></seealso> fetches trace logs + and trace information files from all nodes. The logs are stored in a + new directory named <c>ttb_upload-Filename-Timestamp</c> under the + working directory of the trace control node. Fetching can be disabled + by providing option <c>nofetch</c> to <c>ttb:stop/1</c>. The user can + specify a fetch directory by passing option <c>{fetch_dir, Dir}</c>. </p> - <p>If the option <c>format</c> is given to <c>ttb:stop/1</c>, the + <p>If option <c>format</c> is specified to <c>ttb:stop/1</c>, the trace logs are automatically formatted after tracing is stopped. </p> @@ -742,117 +779,122 @@ f3() -> <section> <title>History and Configuration Files</title> - <p>For the tracing functionality, <c>dbg</c> could be used instead - of the <c>ttb</c> for setting trace flags on processes and trace - patterns for call trace, i.e. the functions <c>p</c>, <c>tp</c>, - <c>tpl</c>, <c>ctp</c>, <c>ctpl</c> and <c>ctpg</c>. There are only - two things added by <c>ttb</c> for these functions: + <p>For the tracing functionality, + <seealso marker="runtime_tools:dbg"><c>dbg</c></seealso> + can be used instead + of <c>ttb</c> for setting trace flags on processes and trace + patterns for call trace, that is, the functions + <c>p</c>, <c>tp</c>, <c>tpl</c>, <c>ctp</c>, <c>ctpl</c>, and <c>ctpg</c>. Only the + following two things are added by <c>ttb</c> for these functions:</p> <list type="bulleted"> - <item>all calls are stored in the history buffer and can be + <item>All calls are stored in the history buffer and can be recalled and stored in a configuration file. This makes it - easy to setup the same trace environment e.g. if you want to - compare two test runs. It also reduces the amount of - typing when using <c>ttb</c> from the erlang shell;</item> - <item>shortcuts are provided for the most common match - specifications (in order not to force the user to use - <c>dbg:fun2ms</c> continually</item>). + easy to set up the same trace environment, for example, if you + want to compare two test runs. It also reduces the amount of + typing when using <c>ttb</c> from the Erlang shell.</item> + <item>Shortcuts are provided for the most common match + specifications (to not force you to use + <seealso marker="runtime_tools:dbg#fun2ms/1"><c>dbg:fun2ms</c></seealso> + continually).</item> </list> - </p> - <p>Use <c>list_history/0</c> to see the content of the history - buffer, and <c>run_history/1</c> to re-execute one of the entries. + <p>Use + <seealso marker="ttb#list_history/0"><c>ttb:list_history/0</c></seealso> + to see the content of the history buffer and + <seealso marker="ttb#run_history/1"><c>ttb:run_history/1</c></seealso> + to re-execute one of the entries. </p> <p>The main purpose of the history buffer is the possibility to create configuration files. Any function stored in the history buffer can be written to a configuration file and used for - creating a specific configuration at any time with one single + creating a specific configuration at any time with a single function call. </p> <p>A configuration file is created or extended with - <c>write_config/2/3</c>. Configuration files are binary files + <seealso marker="ttb#write_config/2"><c>ttb:write_config/2,3</c></seealso>. + Configuration files are binary files and can therefore only be read and written with functions provided by <c>ttb</c>. </p> - <p>You can write the complete content of the history buffer to a - config file by calling - <c>ttb:write_config(ConfigFile,all)</c>. And you can write - selected entries from the history by calling + <p>The complete content of the history buffer can be written to a + configuration file by calling + <c>ttb:write_config(ConfigFile,all)</c>. Selected entries from + the history can be written by calling <c>ttb:write_config(ConfigFile,NumList)</c>, where <c>NumList</c> is a list of integers pointing out the history entries to write. Moreover, the history buffer is always dumped - to <c>ttb_last_config</c> when <c>ttb:stop/0/1</c> is called. + to <c>ttb_last_config</c> when <c>ttb:stop/0,1</c> is called. </p> - <p>User defined entries can also be written to a config file by - calling the function - <c>ttb:write_config(ConfigFile,ConfigList)</c> where + <p>User-defined entries can also be written to a configuration file + by calling function + <c>ttb:write_config(ConfigFile,ConfigList)</c>, where <c>ConfigList</c> is a list of <c>{Module,Function,Args}</c>. </p> <p>Any existing file <c>ConfigFile</c> is deleted and a new file - is created when <c>write_config/2</c> is called. The option - <c>append</c> can be used if you wish to add something at the end - of an existing config file, e.g. + is created when <c>write_config/2</c> is called. Option + <c>append</c> can be used to add something at the end + of an existing configuration file, for example, <c>ttb:write_config(ConfigFile,What,[append])</c>. </p> - <section> - <title>Example: History and configuration files</title> - <p>See the content of the history buffer</p> - <code type="none"><![CDATA[ -(tiger@durin)191> ttb:tracer(). + <p><em>Example:</em></p> + <p>See the content of the history buffer:</p> + <pre> +(tiger@durin)191> <input>ttb:tracer().</input> {ok,[tiger@durin]} -(tiger@durin)192> ttb:p(self(),[garbage_collection,call]). -{ok,{[<0.1244.0>],[garbage_collection,call]}} -(tiger@durin)193> ttb:tp(ets,new,2,[]). +(tiger@durin)192> <input>ttb:p(self(),[garbage_collection,call]).</input> +{ok,{[<0.1244.0>],[garbage_collection,call]}} +(tiger@durin)193> <input>ttb:tp(ets,new,2,[]).</input> {ok,[{matched,1}]} -(tiger@durin)194> ttb:list_history(). +(tiger@durin)194> <input>ttb:list_history().</input> [{1,{ttb,tracer,[tiger@durin,[]]}}, - {2,{ttb,p,[<0.1244.0>,[garbage_collection,call]]}}, - {3,{ttb,tp,[ets,new,2,[]]}}] ]]></code> + {2,{ttb,p,[<0.1244.0>,[garbage_collection,call]]}}, + {3,{ttb,tp,[ets,new,2,[]]}}]</pre> <p>Execute an entry from the history buffer:</p> - <code type="none"><![CDATA[ -(tiger@durin)195> ttb:ctp(ets,new,2). + <pre> +(tiger@durin)195> <input>ttb:ctp(ets,new,2).</input> {ok,[{matched,1}]} -(tiger@durin)196> ttb:list_history(). +(tiger@durin)196> <input>ttb:list_history().</input> [{1,{ttb,tracer,[tiger@durin,[]]}}, - {2,{ttb,p,[<0.1244.0>,[garbage_collection,call]]}}, + {2,{ttb,p,[<0.1244.0>,[garbage_collection,call]]}}, {3,{ttb,tp,[ets,new,2,[]]}}, {4,{ttb,ctp,[ets,new,2]}}] -(tiger@durin)197> ttb:run_history(3). +(tiger@durin)197> <input>ttb:run_history(3).</input> ttb:tp(ets,new,2,[]) -> -{ok,[{matched,1}]} ]]></code> +{ok,[{matched,1}]}</pre> <p>Write the content of the history buffer to a configuration file:</p> - <code type="none"><![CDATA[ -(tiger@durin)198> ttb:write_config("myconfig",all). + <pre> +(tiger@durin)198> <input>ttb:write_config("myconfig",all).</input> ok -(tiger@durin)199> ttb:list_config("myconfig"). +(tiger@durin)199> <input>ttb:list_config("myconfig").</input> [{1,{ttb,tracer,[tiger@durin,[]]}}, - {2,{ttb,p,[<0.1244.0>,[garbage_collection,call]]}}, + {2,{ttb,p,[<0.1244.0>,[garbage_collection,call]]}}, {3,{ttb,tp,[ets,new,2,[]]}}, {4,{ttb,ctp,[ets,new,2]}}, - {5,{ttb,tp,[ets,new,2,[]]}}] ]]></code> + {5,{ttb,tp,[ets,new,2,[]]}}]</pre> <p>Extend an existing configuration:</p> - <code type="none"><![CDATA[ -(tiger@durin)200> ttb:write_config("myconfig",[{ttb,tp,[ets,delete,1,[]]}], -[append]). + <pre> +(tiger@durin)200> <input>ttb:write_config("myconfig",[{ttb,tp,[ets,delete,1,[]]}], +[append]).</input> ok -(tiger@durin)201> ttb:list_config("myconfig"). +(tiger@durin)201> <input>ttb:list_config("myconfig").</input> [{1,{ttb,tracer,[tiger@durin,[]]}}, - {2,{ttb,p,[<0.1244.0>,[garbage_collection,call]]}}, + {2,{ttb,p,[<0.1244.0>,[garbage_collection,call]]}}, {3,{ttb,tp,[ets,new,2,[]]}}, {4,{ttb,ctp,[ets,new,2]}}, {5,{ttb,tp,[ets,new,2,[]]}}, - {6,{ttb,tp,[ets,delete,1,[]]}}] ]]></code> + {6,{ttb,tp,[ets,delete,1,[]]}}]</pre> <p>Go back to a previous configuration after stopping Trace Tool Builder:</p> - <code type="none"><![CDATA[ -(tiger@durin)202> ttb:stop(). + <pre> +(tiger@durin)202> <input>ttb:stop().</input> ok -(tiger@durin)203> ttb:run_config("myconfig"). +(tiger@durin)203> <input>ttb:run_config("myconfig").</input> ttb:tracer(tiger@durin,[]) -> {ok,[tiger@durin]} -ttb:p(<0.1244.0>,[garbage_collection,call]) -> -{ok,{[<0.1244.0>],[garbage_collection,call]}} +ttb:p(<0.1244.0>,[garbage_collection,call]) -> +{ok,{[<0.1244.0>],[garbage_collection,call]}} ttb:tp(ets,new,2,[]) -> {ok,[{matched,1}]} @@ -866,133 +908,135 @@ ttb:tp(ets,new,2,[]) -> ttb:tp(ets,delete,1,[]) -> {ok,[{matched,1}]} -ok ]]></code> +ok</pre> <p>Write selected entries from the history buffer to a configuration file:</p> - <code type="none"><![CDATA[ -(tiger@durin)204> ttb:list_history(). + <pre> +(tiger@durin)204> <input>ttb:list_history().</input> [{1,{ttb,tracer,[tiger@durin,[]]}}, - {2,{ttb,p,[<0.1244.0>,[garbage_collection,call]]}}, + {2,{ttb,p,[<0.1244.0>,[garbage_collection,call]]}}, {3,{ttb,tp,[ets,new,2,[]]}}, {4,{ttb,ctp,[ets,new,2]}}, {5,{ttb,tp,[ets,new,2,[]]}}, {6,{ttb,tp,[ets,delete,1,[]]}}] -(tiger@durin)205> ttb:write_config("myconfig",[1,2,3,6]). +(tiger@durin)205> <input>ttb:write_config("myconfig",[1,2,3,6]).</input> ok -(tiger@durin)206> ttb:list_config("myconfig"). +(tiger@durin)206> <input>ttb:list_config("myconfig").</input> [{1,{ttb,tracer,[tiger@durin,[]]}}, - {2,{ttb,p,[<0.1244.0>,[garbage_collection,call]]}}, + {2,{ttb,p,[<0.1244.0>,[garbage_collection,call]]}}, {3,{ttb,tp,[ets,new,2,[]]}}, {4,{ttb,tp,[ets,delete,1,[]]}}] -(tiger@durin)207> ]]></code> - </section> +(tiger@durin)207></pre> </section> <section> <title>Sequential Tracing</title> <p>To learn what sequential tracing is and how it can be used, - please turn to the reference manual for the - <em><c>seq_trace</c></em> module in the <em><c>kernel</c></em> - application. + see the Reference Manual for + <seealso marker="kernel:seq_trace"><c>seq_trace</c></seealso>. </p> - <p>The support for sequential tracing provided by the Trace Tool - Builder includes </p> + <p>The support for sequential tracing provided by Trace Tool + Builder includes the following:</p> <list type="bulleted"> <item>Initiation of the system tracer. This is automatically - done when a trace port is started with <c>ttb:tracer/0/1/2</c></item> - <item>Creation of match specifications which activates - sequential tracing</item> + done when a trace port is started with + <seealso marker="ttb#tracer/0"><c>ttb:tracer/0,1,2</c></seealso>.</item> + <item>Creation of match specifications that activates + sequential tracing.</item> </list> - <p>Starting sequential tracing requires that a tracer has been - started with the <c>ttb:tracer/0/1/2</c> function. Sequential - tracing can then either be started via a trigger function with a - match specification created with <c>ttb:seq_trigger_ms/0/1</c>, - or directly by using the <c>seq_trace</c> module in the - <c>kernel</c> application. + <p>Starting sequential tracing requires that a tracer is + started with function <c>ttb:tracer/0,1,2</c>. Sequential + tracing can then be started in either of the following ways: </p> + <list type="bulleted"> + <item>Through a trigger function with a match specification + created with + <seealso marker="ttb#seq_trigger_ms/0"><c>ttb:seq_trigger_ms/0,1</c></seealso>.</item> + <item>Directly by using module + <seealso marker="kernel:seq_trace"><c>seq_trace</c></seealso>.</item> + </list> - <section> - <title>Example: Sequential tracing</title> - <p>In the following example, the function + <p><em>Example 1:</em></p> + <p>In the following example, function <c>dbg:get_tracer/0</c> is used as trigger for sequential tracing:</p> - <code type="none"><![CDATA[ -(tiger@durin)110> ttb:tracer(). + <pre> +(tiger@durin)110> <input>ttb:tracer().</input> {ok,[tiger@durin]} -(tiger@durin)111> ttb:p(self(),call). -{ok,{[<0.158.0>],[call]}} -(tiger@durin)112> ttb:tp(dbg,get_tracer,0,ttb:seq_trigger_ms(send)). +(tiger@durin)111> <input>ttb:p(self(),call).</input> +{ok,{[<0.158.0>],[call]}} +(tiger@durin)112> <input>ttb:tp(dbg,get_tracer,0,ttb:seq_trigger_ms(send)).</input> {ok,[{matched,1},{saved,1}]} -(tiger@durin)113> dbg:get_tracer(), seq_trace:reset_trace(). +(tiger@durin)113> <input>dbg:get_tracer(), seq_trace:reset_trace().</input> true -(tiger@durin)114> ttb:stop(format). -({<0.158.0>,{shell,evaluator,3},tiger@durin}) call dbg:get_tracer() -SeqTrace [0]: ({<0.158.0>,{shell,evaluator,3},tiger@durin}) -{<0.237.0>,dbg,tiger@durin} ! {<0.158.0>,{get_tracer,tiger@durin}} +(tiger@durin)114> <input>ttb:stop(format).</input> +({<0.158.0>,{shell,evaluator,3},tiger@durin}) call dbg:get_tracer() +SeqTrace [0]: ({<0.158.0>,{shell,evaluator,3},tiger@durin}) +{<0.237.0>,dbg,tiger@durin} ! {<0.158.0>,{get_tracer,tiger@durin}} [Serial: {0,1}] -SeqTrace [0]: ({<0.237.0>,dbg,tiger@durin}) -{<0.158.0>,{shell,evaluator,3},tiger@durin} ! {dbg,{ok,#Port<0.222>}} +SeqTrace [0]: ({<0.237.0>,dbg,tiger@durin}) +{<0.158.0>,{shell,evaluator,3},tiger@durin} ! {dbg,{ok,#Port<0.222>}} [Serial: {1,2}] ok -(tiger@durin)116> ]]></code> - <p>Starting sequential tracing with a trigger is actually more +(tiger@durin)116></pre> + <p><em>Example 2:</em></p> + <p>Starting sequential tracing with a trigger is more useful if the trigger function is not called directly from the shell, but rather implicitly within a larger system. When calling a function from the shell, it is simpler to start - sequential tracing directly, e.g.</p> - <code type="none"><![CDATA[ -(tiger@durin)116> ttb:tracer(). + sequential tracing directly, for example, as follows:</p> + <pre> +(tiger@durin)116> <input>ttb:tracer().</input> {ok,[tiger@durin]} -(tiger@durin)117> seq_trace:set_token(send,true), dbg:get_tracer(), -seq_trace:reset_trace(). +(tiger@durin)117> <input>seq_trace:set_token(send,true), dbg:get_tracer(), +seq_trace:reset_trace().</input> true -(tiger@durin)118> ttb:stop(format). -SeqTrace [0]: ({<0.158.0>,{shell,evaluator,3},tiger@durin}) -{<0.246.0>,dbg,tiger@durin} ! {<0.158.0>,{get_tracer,tiger@durin}} +(tiger@durin)118> <input>ttb:stop(format).</input> +SeqTrace [0]: ({<0.158.0>,{shell,evaluator,3},tiger@durin}) +{<0.246.0>,dbg,tiger@durin} ! {<0.158.0>,{get_tracer,tiger@durin}} [Serial: {0,1}] -SeqTrace [0]: ({<0.246.0>,dbg,tiger@durin}) -{<0.158.0>,{shell,evaluator,3},tiger@durin} ! {dbg,{ok,#Port<0.229>}} +SeqTrace [0]: ({<0.246.0>,dbg,tiger@durin}) +{<0.158.0>,{shell,evaluator,3},tiger@durin} ! {dbg,{ok,#Port<0.229>}} [Serial: {1,2}] ok -(tiger@durin)120> ]]></code> - <p>In both examples above, the <c>seq_trace:reset_trace/0</c> - resets the trace token immediately after the traced function in - order to avoid lots of trace messages due to the printouts in - the erlang shell. +(tiger@durin)120></pre> + <p>In both previous examples, <c>seq_trace:reset_trace/0</c> + resets the trace token immediately after the traced function + to avoid many trace messages because of the printouts in + the Erlang shell. </p> - <p>All functions in the <c>seq_trace</c> module, except - <c>set_system_tracer/1</c>, can be used after the trace port has - been started with <c>ttb:tracer/0/1/2</c>. + <p>All functions in module <c>seq_trace</c>, except + <c>set_system_tracer/1</c>, can be used after the trace port + is started with <c>ttb:tracer/0,1,2</c>. </p> - </section> </section> <section> - <title>Example: Multipurpose trace tool</title> - <p>The module <c>multitrace.erl</c> which can be found in the - <c>src</c> directory of the Observer application implements a + <title>Multipurpose Trace Tool</title> + <p>Module <c>multitrace</c> in + directory <c>src</c> of the Observer application provides a small tool with three possible trace settings. The trace messages - are written to binary files which can be formatted with the - function <em><c>multitrace:format/1/2</c></em>. + are written to binary files, which can be formatted with + function <c>multitrace:format/1,2</c>: </p> <taglist> - <tag><em><c>multitrace:debug(What)</c></em></tag> - <item>Start calltrace on all processes and trace the given + <tag><c>multitrace:debug(What)</c></tag> + <item><p>Start calltrace on all processes and trace the specified function(s). The format handler used is - <c>multitrace:handle_debug/4</c> which prints each call and - return. <c>What</c> must be an item or a list of items to trace, - given on the format <c>{Module,Function,Arity}</c>, - <c>{Module,Function}</c> or just <c>Module</c>.</item> - <tag><em><c>multitrace:gc(Procs)</c></em></tag> - <item>Trace garbage collection on the given process(es). The - format handler used is <c>multitrace:handle_gc/4</c> which - prints start and stop and the time spent for each GC.</item> - <tag><em><c>multitrace:schedule(Procs)</c></em></tag> - <item>Trace in- and out-scheduling on the given process(es). The - format handler used is <c>multitrace:handle_schedule/4</c> which - prints each in and out scheduling with process, timestamp and + <c>multitrace:handle_debug/4</c> that prints each call and + returns. <c>What</c> must be an item or a list of items to trace, + specified on the format <c>{Module,Function,Arity}</c>, + <c>{Module,Function}</c>, or only <c>Module</c>.</p></item> + <tag><c>multitrace:gc(Procs)</c></tag> + <item><p>Trace garbage collection on the specified process(es). The + format handler used is <c>multitrace:handle_gc/4</c> that + prints start, stop, and the time spent for each garbage collection.</p></item> + <tag><c>multitrace:schedule(Procs)</c></tag> + <item><p>Trace in-scheduling and out-scheduling on the specified process(es). + The format handler used is <c>multitrace:handle_schedule/4</c> that + prints each in-scheduling and out-scheduling with process, time-stamp, and current function. It also prints the total time each traced - process was scheduled in.</item> + process was scheduled in.</p></item> </taglist> </section> </chapter> |
