Automatic Identification of Bug-Introducing Changes .

1. Automatic Identification of Bug-Introducing Changes. Presenter: Haroon Malik

2. Abstract • Bug-fixes do not contain information about the change that initially introduced the bug. • Extraction of bug-introducing changes is challenging. • An algorithm to automatically and accurately identify a bug-introducing changes. • Algorithm can remove 30%~51% of false positive and 14%~15% of false negative to previous algorithm.

3. Introduction • Software project control their changes using SCM and capture bug reports using bug tracking software e.g Bugzilla. • Records which changed in SCM system fixes a Specific bug in the change tracking system. • Bug Progression: • Programmer makes the change • Bug-introducing change • Bug manifest itself in some undesirable external behavior. • Recorded in bug tracking system • Developer modifies the code to fix bug • Bug-fix change

4. Introduction (Cont’d) • Wide spread use of SCM, data concerning bug fix changes in readily availble. • It is easy to mine SCM repository to mine changes that have repaired a bug • Linking key words with bug report refrence • E.g: “Bug” or “Fixed” #902340

5. Major Problems with bug-fix data • It shed no light on when a bug was injected • Not always person who fixes a bug is one who caused • Can not determine where a bug occurred.

6. Background • SZZ Algoritham • Working: • Firstly locates key words to mark bug-fixed changes • Secondly, running a diff tool what changed in bug-fix • Diff tool returns “Hunk” • Utilizes annotate feature of SCM to find the changes • Most recent revision • Who made the chage

7. Background (Cont’d) • Revision1: Origin of bug (Line 3). • Revision 2: Function name changed (bar foo). • Revision 3: Bug removal

8. SZZ Limitations • Blank spaces and Comments • Formatting changes (Line 3) • Name of function containing bug.

9. Proposed Approach • Applied of method level for two java open source projects • Columba and Eclipise • Two human judges manually verified all hunk in series of bug-fix to ensure the corresponding hunks are real bug fixes.

10. Proposed Approach • Steps(1-5) remove 38%~51% of false positive and 14%~15% of false negatives as compared to SZZ.

11. Experimental setup • History Extraction • Used Kenyon to extract histories from SCM systems

12. Experimental setup (Cont’d) • Accuracy Measures • Bug-introducing change set consists of all the changes with in specific project revisions that have been identified as bug-introducing • Assuming R is the more accurate bug-introducing change set, then compute false positives and false negatives for the set P can be computed as follow:

13. Annotation Graph • Annotation Graph • A graph which contains information on the cross-revision mappings of individual lines. • Major improvement over the SZZ

14. Experimental setup (Cont’d) • Non behavior changes • Code format, comments & blank lines. • 14%~20% false positive • Format changes

15. Manual Verification • If a change log indicates the revisions is a bug-fix, it is assumed all the hunks in revision are bug fixes. • Two humans judges marked each bug-fix hunk for both projects. • Used bug-fix hunk verification tool

16. Real Bugs?

17. Validation Hurdles • Non representative systems. • Open Source. • Bug fix data is incomplete. • Manual Varicication

18. Bug-Introduction Statistics Eclipse Columba

19. Conclusion • Refined SSZ approach by introducing Annotation Graph. • Experiments showed the achievement of 38~51% of false positive and 14% of false negative removal as compared to SSZ

20. Thank You