1. Flow-Centric,
Back-In-Time
Debugging
Adrian Lienhard, Julien Fierz
and Oscar Nierstrasz
Software Composition Group
University of Bern, Switzerland

2. Debugger call stack
class Account {
Money balance;
void deposit(Money amount) {
NullPointerException >> this.balance += money;
}
...
}
..................

3. Debugger call stack
class Account {
Money balance;
void deposit(Money amount) {
NullPointerException >> this.balance += money;
}
...
}
class Company {
void pay(Money money, Person person) {
person.account().deposit(money);
}
}
...
where does the
account object
come from?

4. Debugger call stack
class Account {
Money balance;
void deposit(Money amount) {
NullPointerException >> this.balance += money;
}
...
}
class Company {
void pay(Money money, Person person) {
person.account().deposit(money);
}
}
...
where does the
return account object
come from?

5. Debugger call stack
class Account {
Money balance;
void deposit(Money amount) {
NullPointerException >> this.balance += money;
}
...
}
class Company {
void pay(Money money, Person person) {
person.account().deposit(money);
}
}
...
where does the
field read return account object
come from?

6. Debugger call stack
class Account {
Money balance;
void deposit(Money amount) {
this.balance += money;
}
...
}
class Person { class Company {
void createAccount(Bank bank) { void pay(Money money, Person perso
this.account = bank.openAccount(); person.account().deposit(money);
} }
} }
...
where doe
return field write field read return account o
come from

7. class Acc
Money b
void de
this.
}
...
}
class Bank { class Person { class Com
Account openAccount() { void createAccount(Bank bank) { void pa
return new Account(); this.account = bank.openAccount(); perso
} } }
} } }
...
allocation return field write field read

8. In 50% of the cases the execution stack contains
essentially no information about the bug’s cause.
[Liblit PLDI’05]
current call stack
lost method
executions

9. With Back-in-time debuggers,
we have all data we need at hand
complete execution history

10. With Back-in-time debuggers,
we have all data we need at hand
Large amount of data:
programs slow down and run out of memory

11. With Back-in-time debuggers,
we have all data we need at hand
Large amount of data: h ier et
Popt LA'07
al.
S
OOP
programs slow down and run out of memory ard e
tal.
Lienh P'08
O
ECO

12. With Back-in-time debuggers,
we have all data we need at hand
Large amount of data:
programs slow down and run out of memory
developer may not find the root cause

13. Developer: “where did this object come from?”
?
Problem: how far back in time do we need to step?

14. Flow-centric debugging
Object flow (red) mapped to execution trace
14

15. Flow-centric debugging
Object flow (red) mapped to execution trace
15

16. The Compass Debugger
Debugging VM tracks
object flow
Debugger frontend makes
object flow accessible
16

17. Frontend
1 8
2 3 9
4 5
6 7
17

18. Execution trace visualization
selected method
stack
depth
method
start time
18

19. Navigating Execution Traces
execution trace
call stack
19

20. Object flow
object flow of a
selected value method trace
execution stack object flow list
20

21. short demo...
21

22. Compass Frontend
Compass Model Dynamic model Static model
Activation
ASTNode
Alias
Object Flow VM
0..1 *
Activation
program caller
1 context
execution
recording
0..1 * *
* 1
Alias Object
origin value
22

23. Conclusion
Conventional back-in-time debuggers adopt
traditional stack-oriented views
Flow-centric views improve the effectiveness
of debugging
Future work: concurrency bugs
Prototype:
http://scg.iam.unibe.ch/research/objectflow
23