Causal-Consistent Reversible Debugging › lanese › work › Grenoble2015-debugger-Mezzina.pdfThe debugger Claudio Antares Mezzina (in collaboration with Elena Giachino and Ivan

Causal-Consistent Reversible Debugging

3rd Cina Meeting, Torino

Claudio Antares Mezzina(in collaboration with Elena Giachino and Ivan Lanese)

February 11, 2015

Contents

1 Introduction

2 The debugger

3 Implementation

4 Conclusions

Claudio Antares Mezzina (in collaboration with Elena Giachino and Ivan Lanese)1/19

Roadmap

1 Introduction

2 The debugger

3 Implementation

4 Conclusions

Reversible Debugging

Jakob Englom, S4D 2012

Reverse debugging is the ability of a debugger to stop after afailure in a program has been observed and to go back into thehistory of the execution to uncover the reason of failure.

Implications

I Ability to execute an application both in forward andbackward way.

I Reproduce or keep track of the past of an execution.

Introduction Claudio Antares Mezzina (in collaboration with Elena Giachino and Ivan Lanese)2/19

Reversibility and Debugging

Question

When a misbehaviour is detected, how one should proceed in orderto retrace the steps that led to the bug?

I Sequential setting: recursively undo the last action.

I Concurrent setting: there is not a clear understanding ofwhich is the last action.


State of the Art for ConcurrentReversible Debugging

Non-deterministic replay

The execution is replayed non deterministically from the start (orfrom the a previous checkpoint) till the desired point.

Deterministic replay/ reverse-execute debugging

A log of the scheduling among threads is kept and then actions arereversed or replayed accordingly.


Drawbacks

Non-deterministic replay:I Actions could get scheduled in a different order and hence the

bug may not be reproduced.

I Particularly difficult to reproduce concurrency problems (e.g.race conditions).

Deterministic replay / reverse execution:

I Also action in threads not related to the bug may be undone.

I If one among several indipendent threads causes the bug, andthis thread has been scheduled as first, then one has to undothe entire execution to find the bug.


Our Approach: Causal-ConsistentReversibility

Actions are reversed respecting the causes:

I only actions that have caused no successive actions can beundone;

I concurrent actions can be reversed in any order;

I dependent actions are reversed starting from theconsequences.

Benefits

The programmer can easily individuate and undo the actions thatcaused a given misbehaviour.


Roadmap

1 Introduction

2 The debugger

3 Implementation

4 Conclusions

Chosen language

I µOz: subset of the Oz language [Van Roy et al.]

I Functional language

I thread-based concurrencyI asynchronous communication via ports (channels)

I µOz advantages:

I well-know stack-based abstract machineI equipped with a causal-consistent reversible

semantics (from previous work)

The debugger Claudio Antares Mezzina (in collaboration with Elena Giachino and Ivan Lanese)7/19

Syntax

S ::=

skip empty stm

S1 S2 sequence

let x = v in S end var declaration

if x then S1 else S2 end conditional

thread S end thread creation

let x = c in S end procedure declaration

{x ỹ} procedure calllet x = NewPort in S end port creation

{Send x y} send on a portlet x = { Receive y } in S end receive from a port

v ::= true | false | N simple valuesc ::= proc {x̃} S end procedures


The Debugger Commands 1/2co

ntr

ol

forth (f) t (forward execution of one step of thread t)

run (runs the program)

rollvariable (rv) id (c-c undo of the creation of variable id)

rollsend (rs) id n (c-c undo of last n send to port id)

rollreceive (rr) id n (c-c undo of last n receive from port id)

rollthread (rt) t (c-c undo of the creation of thread t)

roll (r) t n (c-c undo of n steps of thread t)

back (b) t (backward execution of one step of

thread t (if possible))


The Debugger Commands 2/2ex

plo

re

list (l) (displays all the available threads)

store (s) (displays all the ids contained in the store)

print (p) id (shows the state of a thread, channel, or variable)

history (h) id (shows thread/channel computational history)


Example of execution

let a = true in (1)

let b = false in (2)

let chan = port in (3)

thread {send chan a}; skip; {send chan b} end; (4)let y = {receive chan} in skip end (5)

end (6)

end (7)

end (8)

I at line (4) thread t1 is created from thread t0

I t1 fully executes, then t0 fully executes

I what should be the shape of t0 (and of the port) if t1 rolls of 3steps?


t0 let y = {receive chan} in skip endt1 {send chan a}; skip; {send chan b}x ⊥

I t0 is automatically rolled-back enogh in order to release theread value a

I t0 rolled-back as little as possible (no domino effect)


Debugging Soundness

Properties

1. Every reduction step can be reversed.

2. Every state reached during debugging could have beenreached by forward-only execution from the initial state

Prop 1 ensures that the debugger can undo every forwar step,and, vice-versa, it can re-execute every step previously undone.

Prop 2 ensures that any sequence of debugging commands canonly lead to states which are part of the normal forward-onlycomputations.


Roadmap

1 Introduction

2 The debugger

3 Implementation

4 Conclusions

Implementation

I Java based

I Interpreter of the µOz reversible semantics:

I forward and backward stepsI roll as controlled sequence of the backward stepsI rollvarialbe, rollthread, rollsend and rollreceive are

based on roll

I It keeps history and causality information to enablereversibiliby

http://www.cs.unibo.it/caredeb

Implementation Claudio Antares Mezzina (in collaboration with Elena Giachino and Ivan Lanese)14/19

http://www.cs.unibo.it/caredeb

History and Causality Information

I The history of each thread.

I The history of each channel, containing:

I elements of the form (ta, i, v, tb, j)I ta sent a value v which has been received by tbI i and j are pointes to ta and tb send/receive instructions

I We also maintain the following mappings:

I var name → (thread name, i) pointing to the variablecreator (for rollvar)

I thread name → (thread name, i) pointing to the threadcreator (for rollvar)

I could be retrieved by inspecting histories, but storingthem is much more efficient


Reversing: code snippet

private static void rollTill(HashMap map) {

//map contains pairs

Iterator it = map.keySet (). iterator ();

while(it.hasNext ())

{

String id = it.next ();

int gamma = map.get(id);

// getGamma retrieves the next gamma in the history

while(gamma

Demo Time


Roadmap

1 Introduction

2 The debugger

3 Implementation

4 Conclusions

Future Work

I Improve the debugges user experience

I GUII Eclipse plug-in

I Other form of causality analisys

I Move to more popular programing languages / models

I e.g. Java with Actors

I Causal Consistent Replay

Conclusions Claudio Antares Mezzina (in collaboration with Elena Giachino and Ivan Lanese)18/19

Thank you!

Any Questions?

Conclusions Claudio Antares Mezzina (in collaboration with Elena Giachino and Ivan Lanese)19/19

IntroductionThe debuggerImplementationConclusions

Documents

Causal-Consistent Reversible Debugging › lanese › work › Grenoble2015-debugger-Mezzina.pdfThe debugger Claudio Antares Mezzina (in collaboration with Elena Giachino and Ivan