Debugging AmbientTalk programs using REME-D in Eclipse.
Since version 1.5.0 the AmbientTalk IDE for Eclipse (IdeAT plugin) includes debugging support for concurrent and distributed AmbientTalk programs. The debug module of the IdeAT plugin launches a debugging session with REME-D (read as remedy), a Reflective Epidemic Message-Oriented Debugger for AmbientTalk.
What is REME-D?
REME-D is a on-line distributed debugger which adapts well-known features from sequential debuggers, such as step-by-step execution, state introspection and breakpoints, to the event loop concurrency model. It has been designed to debug applications running in mobile ad hoc networks. Given the dynamic nature of mobile ad hoc networks, a debugging session in REME-D consists of a undetermined, fluctuating number of devices. Devices are dynamically added to the debugging session as they interact with a device forming part of the debugging session, thus terming REME-D an epidemic debugger.
REME-D is itself an ambient-oriented program where communication between debugger and debugged actors happens via asynchronous communication. Our current prototype of REME-D has been implemented in AmbientTalk using its reflective capabilities, and integrated in the IdeAT plugin using the Eclipse Debug Framework.
Need more detail? Read the REME-D paper which also contains more info about how it has been implemented.
In order to explain REME-D UI interaction consider a shopping application that needs to process purchase orders. It works similar to the shopping application used in the post-mortem distributed debugging wiki page. To debug an AmbientTalk application you can right click an .at file and "Debug As..-> AmbientTalk Application" or launch a saved custom AmbientTalk run configuration.
The figure below displays a REME-D debugging session resulting from launching the
buyer.at file in debug mode. The figure displays three views: the debug view on the top right pane, the state inspector on the top left pane, and the editor on the bottom.
Debug view shows that the debugging session is currently composed of one AmbientTalk VM running the
buyer.at file which contains two actors: the default actor (created when an AmbientTalk VM is launched) and an actor created in the line 28 of the
buyer.at file, which we call the buyer actor. Note that the debug view also shows another AmbientTalk VM running the
store.at file. This VM is not part of the debugging session since
store.at was launched in run mode, and thus non of its actors are shown in the debug view.
The editor shows part of the implementation of the buyer.at file which contains a
checkoutShoppingBasket method. This method is called by a customer when he decides to purchase some goods. In response to this action, the buyer actor
go method is called which verifies three things before accepting the order: 1) whether the requested items are still in stock, 2) whether the customer has given valid payment information and 3) whether a shipper can deliver the order in time.
The state inspector shows the state of a paused actor highlighted in grey in the debug view. REME-D supports the introspection of actors whenever they are suspended (in a pause state). An actor can only be suspended between turns. The state inspector shows the objects encapsulated in the actor, as well as the messages that await processing on the actor's message queue. In this example, the buyer actor contains a
customer object and its mailbox a
go message sent by the default actor. While an actor is paused, the state inspector will be updated with each new message that arrive to the actor from other non-paused actors.
Asynchronous Message Breakpoints
In sequential debuggers, breakpoints are placed on statements to mark ''interesting points'' in the execution of the program in which the developer wishes to inspect its state. Such interesting points in ambient-oriented programming take the form of messages passed between actors leading to the concept of asynchronous message breakpoints.
To debug a message, the developer places a breakpoint on the asynchronous message send statement. In the figure above, this is signaled in the editor by a dot next to the breakpointed message (i.e. the
go message). An actor is suspended when a breakpointed message reaches the head of its message queue, before its execution.
One can select at runtime on which devices a given breakpoint will be active by right clicking on the breakpoint and "Configure breakpoint in VM…". A properties page as shown below will be displayed letting the programmer chose in which running AmbientTalk VM should be installed. In this example, there is only one VM running in debug mode. This is an interesting feature to use when debugging peer-to-peer applications. Since all peers load the same source code, by default message breakpoints will be active on all running peers.
REME-D provides two kinds of step commands: step-over and step-into a turn. Stepping over a turn allows the developer to follow the evolution of the actor state as it processes incoming messages. A step-over command instructs an actor to process a single message --the one at the head of the queue-- and return to the paused state.
Stepping into a turn allows the developer to navigate the consequences of processing a given message, i.e the messages sent to other actors in that turn. When the developer instructs REME-D to step into the current turn, the actor will perform a step-over and mark all outgoing asynchronous messages as breakpointed messages.At the end of step-into, the current actor (i.e. the one on which the command was invoked) and all the actors receiving messages sent within that turn are paused. The developer can then assert the effect of the turn on the current actor, and decide which of the now paused receiving actors to continue debugging.
The screenshoot below shows the state of REME-D's UI after having stepped into the turn that processed the
go message shown in first screenshoot. The debug view shows the actor that performed the turn is expanded displaying the messages emitted during the turn (
partInStock), and the three paused actors that received them.
Debugging applications written for mobile ad hoc networks require that the debugging process itself be open. In this sense, REME-D's debugging sessions are not constrained to a fixed configuration. One does not need to define a-priori which devices will participate in the debugging session. Instead, REME-D operates in an epidemic fashion, spontaneously adding devices to the current debugging session whenever they interact with other actors outside the session.
A device is added to the debugging session whenever it receives a breakpointed message from an actor. Whenever a breakpointed message arrives to an actor, the REME-D can reproduce itself on the newly encountered actor (thanks to AmbientTalk reflective capabilities). The actor is then added to the debugging session, thus receiving all debugging information (e.g. the active message breakpoints).
Figure above shows the result of adding the inventory, credit bureau and shipper actors to the debugging session when they receive a breakpointed message from the buyer actor. Those actors are included in the debug view under a different AmbientTalk VM id denoted as an infected VM.
Note that REME-D only infects encountered actors which have declared their willingness to be debugged (i.e. the actor needs to be 'debuggeable'). There are two ways to make an actor debuggeable:
- Launch iat with -Xdebug option. All actors created within this iat will be set debuggeable.
- Make an actor explicitly declare itself as debuggeable by loading the contents of
In this example, the
store.at file run configuration added the -Xdebug option.
Debugging in face of partial failures
In order to deal with the frequent disconnections inherent to mobile ad hoc networks, REME-D communicates with the participating actors via asynchronous messages. As such, communication failures with debugged devices do not affect the debugging of the other devices. Devices leave a debugging session when they disconnect from the network. When REME-D detects a communication failure with an actor within the debugging session, the actor is removed from the debugging session and the debug view shows the actor as terminated.
Since it is impossible to predict if a disconnection is temporary or permanent, REME-D takes a conservative approach and resumes the actor computation removing the debugging support. If the actor would reconnect, it won't be added to the debugging session unless it gets "infected" by an actor still running in the debugging session.
This is first prototype of REME-D for AmbientTalk. Feedback on it is more than welcomed :)
You can send your suggestions and questions to the AmbientTalk? mailing-list or report bugs on the Issues section of this website. Please use the "component_ideAT" label for reporting issues.
Limitations and Known Issues
- Currently, actors running in debug mode can only be part of one debugging session.
- Sometimes UI does not activate step into/over commands when an actor gets paused. Click another actor and back on the paused one and then the UI should show them active.
- Sometimes UI does not update correctly disconnected vms.
- Provide support in REME-D UI to browse causal links that lead to the currently inspected message.
- Add an object graph view on a paused actor.
- Better visualization of far references.
- Support for simultaneous debugging sessions.
- Support to modify state of a paused actor.