<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>8 Remote Debugging</TITLE><LINK href="ozdoc.css" rel="stylesheet" type="text/css"></HEAD><BODY><TABLE align="center" border="0" cellpadding="6" cellspacing="6" class="nav"><TR bgcolor="#DDDDDD"><TD><A href="node7.html#chapter.exceptions"><< Prev</A></TD><TD><A href="index.html">- Up -</A></TD><TD><A href="node9.html#chapter.limitations">Next >></A></TD></TR></TABLE><DIV id="chapter.remote"><H1><A name="chapter.remote">8 Remote Debugging</A></H1><P> So far, we have only used Ozcar to debug threads running in the same process as the debugger itself. However, Ozcar also supports the same features for threads running remotely, and thus also the debugging of distributed applications. </P><DIV class="apropos"><P class="margin">Model</P><P> In this case, debugging is a client/server application. The debugger itself (i. e., the site where the user interface is running) doubles as a server, accepting connections of clients (i. e., debugging sessions on remote sites). Clients forward events to the server, for example when threads stop at step points or become blocked. All attached threads, whether remote or local, are displayed in the same thread forest: Nodes corresponding to remote threads will be named by their site name and process ID in addition to their thread ID. All control operations are supported on remote threads: Commands are sent to the corresponding site so that the actual operations can be carried out locally. </P></DIV><DIV class="apropos"><P class="margin">Reflection</P><P> Note that when inspecting remote stacks, any contained values will be <A name="label26"></A><EM>reflected</EM> before they are displayed. This means that an approximating copy will be made on the remote site and the debugger will only be able to operate on the copy. </P></DIV><DIV class="apropos"><P class="margin">Chapter Structure</P><P> This chapter will first take a look at how the server is started, then at how remote debugging sessions are initiated and how clients connect to the server. </P></DIV><H2><A name="label27">8.1 Starting the Server</A></H2><P> There are two ways to start a server: using the user interface or the API. </P><DIV class="apropos"><P class="margin">Using the Menus</P><P> In the <CODE>Ozcar</CODE> menu, you'll find an entry called <CODE>Start Server</CODE>. Activating this will cause Ozcar to open a port where it listens for clients that want to connect. This port is identified by a <A name="label28"></A><EM>ticket</EM>: a string describing the server's location on the net. Clients will need this ticket in order to connect. A dialog will be opened showing the ticket. You can use ``copy and paste'' to create clients. </P></DIV><DIV class="apropos"><P class="margin">Using the API</P><P> Another way to start the server is to use the API, for instance to start the server automatically from your application or to implement automatic connection of clients. The expression </P><BLOCKQUOTE class="code"><CODE>{Ozcar<SPAN class="keyword">.</SPAN>startServer}</CODE></BLOCKQUOTE><P> will return the required ticket. </P></DIV><DIV class="apropos"><P class="margin">Multiple Activations</P><P> Once Ozcar has started its server, the server will live as long as the Mozart process it runs in. Clicking <CODE>Start Server</CODE> or evaluating <CODE>{Ozcar<SPAN class="keyword">.</SPAN>startServer}</CODE> again will yield the same ticket. </P></DIV><H2><A name="label29">8.2 Connecting a Client to the Server</A></H2><P> Once a server has been started, clients can connect to it. Again, there are two ways to start a client: using the <CODE>ozd</CODE> application or the API. Note that you should not have started Ozcar on the site where you want to start a server: Both debuggers will attempt to take over control of threads and will confuse each other. </P><DIV class="apropos"><P class="margin">From the Command Line</P><P> The command line debugger can be used to start a client: </P><BLOCKQUOTE class="code"><CODE>ozd --remotedebugger --ticket=</CODE><I>ticket</I><CODE> </CODE><I>url</I><CODE> -- </CODE><I>args</I></BLOCKQUOTE><P> This will use <I>ticket</I> to connect to the server. Otherwise, behaviour is similar to <CODE>ozd --debugger</CODE>, see <A href="../tools/node12.html#chapter.debugger">Chapter 4 of ``Oz Shell Utilities''</A> for more information. </P></DIV><DIV class="apropos"><P class="margin">Using the API</P><P> The API provides the module <CODE>OzcarClient</CODE> at URL <CODE>x-oz://system/OzcarClient</CODE>. This can also be used to start a client: </P><BLOCKQUOTE class="code"><CODE>{OzcarClient<SPAN class="keyword">.</SPAN>start </CODE><CODE><I>Ticket</I></CODE><CODE>}</CODE></BLOCKQUOTE><P> </P></DIV><DIV class="apropos"><P class="margin">Fault Handling</P><P> When a client dies, the server will still consider its threads attached. Only when you invoke an operation on a thread will it notice this fact and consider the corresponding thread dead. </P></DIV></DIV><TABLE align="center" border="0" cellpadding="6" cellspacing="6" class="nav"><TR bgcolor="#DDDDDD"><TD><A href="node7.html#chapter.exceptions"><< Prev</A></TD><TD><A href="index.html">- Up -</A></TD><TD><A href="node9.html#chapter.limitations">Next >></A></TD></TR></TABLE><HR><ADDRESS><A href="http://www.ps.uni-sb.de/~lorenz/">Benjamin Lorenz</A> and <A href="http://www.ps.uni-sb.de/~kornstae/">Leif Kornstaedt</A><BR><SPAN class="version">Version 1.4.0 (20090610)</SPAN></ADDRESS></BODY></HTML>
distrib
>
Mandriva
>
2010.0
>
i586
>
media
>
contrib-release
>
by-pkgid
>
bd5c3d824c3db63ffd9226c15941e6ad
>
files
>
1581
