Software Bug Localization with Markov Logic

 
Software Bug Localization with
Markov Logic
 
Sai Zhang
,  Congle Zhang
University of Washington
 
Presented
 
by 
 Todd Schiller
Software bug localization:  finding the likely
buggy code fragments
 
 
A 
software
 system
(source code)
 
Some 
observations
(test results, code coverage,
  bug history,  code dependencies,
  etc.)
 
 
 
 
 
 
A ranked list of likely
buggy code fragments
 
  max(arg1, arg2) {
1.  a = arg1
2.  b = arg2
3.  if (a   b) {
4.      return b;
5.  } else {
6.      return a;
7.  }
  }
 
>=
An example bug localization technique
(Tarantula [
Jones’03
])
 
Input
:     a program +  passing tests + failing tests
Output
:  a list of buggy statements
 
Example:
 
<
 
 arg1 = 1
 arg2 = 2
 
Tests
 
arg1 = 2
arg2 = 1
 
arg1 = 2
arg2 = 2
3.
if (a >= b) {
4.
return b;
1. a = arg1
2. b = arg2
5.
} else {
6.   return a;
Tarantula’s ranking heuristic
Suspiciousness(s) = 
 
Percentage of 
failing
 tests
covering statement s
 
Percentage of 
passing 
tests
covering statement s
 
This heuristic is effective in practice [
Jones’05
]
For a statement: s
Problem: existing techniques lack an interface layer
Heuristics are 
hand crafted
Techniques are often defined in an 
ad-hoc
 way
A persistent problem 
in the research community
Tarantula
Jones ICSE’03
xDebug
Wong, Compsac’07
CBI
Liblit PLDI’05
Raul
ICSE’09
Wang
ICSE’09
 
Static
Code Info
Line
coverage
Predicate
Def-use
relations
Branch
coverage
 
 
Observations
Techniques
Adding an interface layer
Tarantula
Jones ICSE’03
xDebug
Wong, Compsac’07
CBI
Liblit PLDI’05
Raul
ICSE’09
Wang
ICSE’09
Static
Code Info
Line
coverage
Predicate
Def-use
relations
Branch
coverage
Interface layer
 
Why
 an interface layer?
 
     Focus on key design insights
 
     Avoid “magic numbers “ in heuristics
 
     Fair basis for comparison
 
     Fast prototyping
 
Who should be the interface layer?
Tarantula
Jones ICSE’03
xDebug
Wong, Compsac’07
CBI
Liblit PLDI’05
Raul
ICSE’09
Wang
ICSE’09
 
Static
Code Info
Line
coverage
Predicate
Def-use
relations
Branch
coverage
 
 
Markov logic 
network
 as an interface layer
Tarantula
Jones ICSE’03
xDebug
Wong, Compsac’07
CBI
Liblit PLDI’05
Raul
ICSE’09
Wang
ICSE’09
 
Static
Code Info
Line
coverage
Predicate
Def-use
relations
Branch
coverage
 
Markov Logic Network
Why Markov Logic Network
[Richardson’05]?
 
Use first order logic to express key insights
E.g.,  estimate the likelihood of 
cancer(x)
 for people 
x
    
Example rules:
     
smoke(x) => cancer(x)
     
smoke(x) 
  
friend(x,y) => smoke(y)
     
friends(x, y)
 
 
friends(y, z) => friends(x, z)
smoke causes cancer
you will smoke if your
friend smokes
friends of friends are
friends
Why Markov Logic Network
[Richardson’05]?
Use first order logic to express key insights
E.g.,  estimate the likelihood of 
cancer(x)
 for people 
x
    
Example rules:
     
smoke(x) => cancer(x)
     
smoke(x) 
  
friend(x,y) => smoke(y)
     
friends(x, y)
 
 
friends(y, z) => friends(x, z)
Efficient weight learning and inference
Learning rule weights from training data
Estimate 
cancer(x)
 for a new data point
 
w1
 
w2
 
w3
(details omitted here)
Markov logic for bug localization
 
First-order logic rules
  (capture insights)
Alchemy
(learning)
 
A markov logic network engine
 
Training data
Alchemy
(inference)
 
Rule weights
 
A statement: s
 
Likelihood of s
being buggy
 
Markov logic for bug localization
 
Researchers
 
First-order logic rules
Alchemy
(learning)
 
A markov logic network engine
 
Training data
Alchemy
(inference)
 
Rule weights
 
A statement: s
 
Likelihood of s
being buggy
 
Different rules for
different bug localization algorithms
Our prototype: MLNDebugger
 
First-order rules
1.
cover(test, s)
 
 fail(test) => buggy(s)
2.
cover(test, s)
 
 pass(test) => ¬ buggy(s)
3.
control_dep(s1, s2)
 
 buggy(s1) => ¬ buggy(s2)
4.
data_dep(s1, s2)
 
 buggy(s1) => ¬ buggy(s2)
5. wasBuggy(s) => buggy(s)
 
Learning and inference
 
Rules + Weights
 
A statement:
stmt
 
How likely 
stmt 
is buggy
A statement covered by a
failing test is buggy
If a statement  has control
dependence on a buggy
statement, then it is not buggy
If a statement  has data flow
dependence on a buggy
statement, then it is not buggy
A statement that was buggy
before is buggy
A statement covered by a
passing test is not buggy
 
Evaluating MLNDebugger on 4
Siemens benchmarks
 
80+ seeded bugs
2/3 as training set
1/3 as testing set
 
Measurement on the testing set
Return 
top
 
k
 suspicious 
statements, check the
percentage of 
buggy ones 
they can cover.
 
Baseline: Tarantula [Jones’ ICSE 2003]
 
Experimental results
 
Tarantula
 
MLNDebugger
 
More in the paper…
 
Formal definition
Inference algorithms
Implementation details
Implications to the bug localization research
 
Contributions
 
The first 
unified framework 
for automated debugging
Markov logic network 
as 
an interface layer
: expressive, concise, and
elegant
 
A proof-of-concept 
new debugging technique 
using the
framework
 
An 
empirical study
 
on 4 programs
80+ versions, 8000+ tests
Outperform a well-known technique
Slide Note
Embed
Share

Software bug localization techniques like Tarantula focus on finding likely buggy code fragments in a software system by analyzing test results, code coverage, bug history, and code dependencies. The lack of an interface layer in existing techniques leads to handcrafted heuristics, posing a persistent problem in the research community. Adding an interface layer can provide key design insights, avoid ad-hoc definitions, and enable fair comparisons between techniques.

  • Bug Localization
  • Software Systems
  • Markov Logic
  • Interface Layer

Uploaded on Oct 06, 2024 | 0 Views


Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.

E N D

Presentation Transcript


  1. Software Bug Localization with Markov Logic Sai Zhang, Congle Zhang University of Washington Presented by Todd Schiller

  2. Software bug localization: finding the likely buggy code fragments A software system (source code) Some observations (test results, code coverage, bug history, code dependencies, etc.) A ranked list of likely buggy code fragments

  3. An example bug localization technique (Tarantula [Jones 03]) Input: a program + passing tests + failing tests Output: a list of buggy statements 3. if (a >= b) { 4. return b; 1. a = arg1 2. b = arg2 5. } else { 6. return a; Tests Example: arg1 = 2 arg2 = 1 arg1 = 2 arg2 = 2 arg1 = 1 arg2 = 2 max(arg1, arg2) { 1. a = arg1 2. b = arg2 3. if (a b) { 4. return b; 5. } else { 6. return a; 7. } } >= <

  4. Tarantulas ranking heuristic For a statement: s %????(?) Suspiciousness(s) = %???? ? + %????(?) Percentage of failing tests covering statement s Percentage of passing tests covering statement s This heuristic is effective in practice [Jones 05]

  5. Problem: existing techniques lack an interface layer Heuristics are hand crafted Techniques are often defined in an ad-hoc way A persistent problem in the research community Tarantula Jones ICSE 03 xDebug CBI Raul ICSE 09 Wang ICSE 09 Techniques Liblit PLDI 05 Wong, Compsac 07 Static Code Info Line Branch coverage Def-use relations Predicate Observations coverage

  6. Adding an interface layer Tarantula Jones ICSE 03 Why an interface layer? Focus on key design insights Avoid magic numbers in heuristics Fair basis for comparison Fast prototyping xDebug CBI Raul ICSE 09 Wang ICSE 09 Liblit PLDI 05 Wong, Compsac 07 Interface layer Static Code Info Line Branch coverage Def-use relations Predicate coverage

  7. Who should be the interface layer? Tarantula Jones ICSE 03 xDebug CBI Raul ICSE 09 Wang ICSE 09 Liblit PLDI 05 Wong, Compsac 07 Static Code Info Line Branch coverage Def-use relations Predicate coverage

  8. Markov logic network as an interface layer Tarantula Jones ICSE 03 xDebug CBI Raul ICSE 09 Wang ICSE 09 Liblit PLDI 05 Wong, Compsac 07 Markov Logic Network Static Code Info Line Branch coverage Def-use relations Predicate coverage

  9. Why Markov Logic Network [Richardson 05]? Use first order logic to express key insights E.g., estimate the likelihood of cancer(x) for people x Example rules: smoke(x) => cancer(x) smoke(x) friend(x,y) => smoke(y) friends(x, y) friends(y, z) => friends(x, z) smoke causes cancer you will smoke if your friend smokes friends of friends are friends

  10. Why Markov Logic Network [Richardson 05]? Use first order logic to express key insights E.g., estimate the likelihood of cancer(x) for people x Example rules: smoke(x) => cancer(x) smoke(x) friend(x,y) => smoke(y) friends(x, y) friends(y, z) => friends(x, z) w3 w1 w2 Efficient weight learning and inference Learning rule weights from training data Estimate cancer(x) for a new data point (details omitted here)

  11. Markov logic for bug localization Training data First-order logic rules (capture insights) Alchemy (learning) Researchers A markov logic network engine Rule weights Alchemy (inference) Likelihood of s being buggy A statement: s

  12. Markov logic for bug localization Different rules for different bug localization algorithms Training data First-order logic rules Alchemy (learning) Researchers A markov logic network engine Rule weights Alchemy (inference) Likelihood of s being buggy A statement: s

  13. Our prototype: MLNDebugger First-order rules 1. cover(test, s) fail(test) => buggy(s) 2. cover(test, s) pass(test) => buggy(s) 3. control_dep(s1, s2) buggy(s1) => buggy(s2) 4. data_dep(s1, s2) buggy(s1) => buggy(s2) 5. wasBuggy(s) => buggy(s) failing test is buggy If a statement has control dependence on a buggy statement, then it is not buggy dependence on a buggy statement, then it is not buggy before is buggy Buggy! if(foo(x)) { bar(); } A statement covered by a A statement covered by a passing test is not buggy Learning and inference If a statement has data flow v = foo() bar(v) Buggy! Rules + Weights A statement that was buggy A statement: stmt Correct! Buggy! Correct! Correct! How likely stmt is buggy

  14. Evaluating MLNDebugger on 4 Siemens benchmarks 80+ seeded bugs 2/3 as training set 1/3 as testing set Measurement on the testing set Return topk suspicious statements, check the percentage of buggy ones they can cover. Baseline: Tarantula [Jones ICSE 2003]

  15. Experimental results MLNDebugger Tarantula

  16. More in the paper Formal definition Inference algorithms Implementation details Implications to the bug localization research

  17. Contributions The first unified framework for automated debugging Markov logic network as an interface layer: expressive, concise, and elegant A proof-of-concept new debugging technique using the framework An empirical study on 4 programs 80+ versions, 8000+ tests Outperform a well-known technique

Related


More Related Content

giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#