Which Warnings Should I Fix First?
Upcoming SlideShare
Loading in...5
×
 

Which Warnings Should I Fix First?

on

  • 1,753 views

2007 European Software Engineering Conference and 2007 Foundations of Software Engineering (ESEC/FSE 2007)

2007 European Software Engineering Conference and 2007 Foundations of Software Engineering (ESEC/FSE 2007)

Statistics

Views

Total Views
1,753
Views on SlideShare
1,752
Embed Views
1

Actions

Likes
0
Downloads
24
Comments
0

1 Embed 1

http://www.slideshare.net 1

Accessibility

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • We are going to use History since it gives the answer

Which Warnings Should I Fix First? Which Warnings Should I Fix First? Presentation Transcript

  • Sung Kim and Michael D. Ernst {hunkim, mernst}@csail.mit.edu CSAIL • MIT
  • Sung Kim and Michael D. Ernst {hunkim, mernst}@csail.mit.edu CSAIL • MIT
  • Static analysis I can find bugs for you!
  • Bug-finding tool
  • Warnings
  • Warning examples
  • Bug candidate - Warning Category : Style - empty try/catch Priority : 3
  • Are warnings useful? Are all warnings important to be fixed? Does tools’ prioritization help to identify important ones?
  • Experimental methodology
    • Select source code (a snapshot)
    • Mark buggy lines
      • Lines are changed in later fixes
    • Compare with warnings from bug-finding tools
    • Measure precision
      • High precision indicates important warnings
  • Subject tools and projects
    • Three bug-finding tools
      • FindBugs, JLint, and PMD
    • Three open source projects
    Projects Software type # of revisions Period LOC(K) Columba Email client 1,703 2002/11~2004/06 121 Lucene Search engine 929 2001/10~2006/11 37 Scarab Issue tracker 870 2002/01~2006/11 64
  • Buggy lines Rev 100 …… Mark as a buggy line if a line is changed in future fixes.
  • Change logs indicate fixes …… [bugfix] Fixed bug #3576 fix File 1 Non-fix Non-fix Non-fix Non-fix
  • Buggy lines Rev 199 Rev 200 Fix If (x=y && Z=x) {
  • Buggy lines Rev 199 Rev 198 If (x=y && Z=x) { If (x=y && Z=x) { marks Fix
  • Buggy lines Rev 100 Rev 200 Rev 199 Rev 198 ……
  • Warning evaluation Rev 100 50% of warnings are fixed later
  • Evaluate warnings at revision n/2 Rev n/2 Rev n Mark buggy lines Rev n/2+1
  • Are warnings important? NO only 3~18% are fixed!
  • Does tools’ prioritization help? NO Tools’ priority 1 warnings are not better.
  • Does tools’ prioritization help?
  • Does tools’ prioritization help?
  • Does tools’ prioritization help? No, high priority warnings do not have high precision!
  • …… Our solution: using change history Warning A File Warning B Foo ……
    • Compute score of each warning category using history
      • Observe warning removals in history
      • If a warning is removed in a change
        • Score promotes by non-fix-weight (0.1)
      • If a warning is removed in a fix-change
        • Score promotes by fix-weight (0.9)
      • Assume high score warnings are important
    Reprioritization algorithm
  • Reprioritization algorithm …… Score(A) += non-fix-weight (0.1) Score(A) += fix-weight (0.9) Fixed bug #3576 Score(A) += Non-fix-weight(0.1) Score(A)=1.1 fix Score(A)=0 Score(A)=0.1 Score(A)=1 Warning A File 1 Warning B Foo …… Score(B)=0
  • Evaluation Rev n/2-1 Rev n/2 Rev 1 Train warnings Rev n Mark buggy lines Rev n/2+1
  • Comparison
    • History -based warning prioritization
    • Tools ’ warning prioritization
    • Compare precision of top 100 warnings
  • Columba
  • Columba
  • Lucene
  • Lucene
  • Scarab
  • Scarab
  • Summary
  • Sung Kim and Michael D. Ernst {hunkim, mernst}@csail.mit.edu CSAIL • MIT