ACM Home Page
Please provide us with feedback. Feedback
Patches as better bug reports
Full text PdfPdf (249 KB)
Source Generative Programming And Component Engineering archive
Proceedings of the 5th international conference on Generative programming and component engineering table of contents
Portland, Oregon, USA
SESSION: Measurement and evaluation table of contents
Pages: 181 - 190  
Year of Publication: 2006
ISBN:1-59593-237-2
Author
Westley Weimer  University of Virginia
Sponsors
SIGPLAN: ACM Special Interest Group on Programming Languages
ACM: Association for Computing Machinery
Publisher
ACM  New York, NY, USA
Bibliometrics
Downloads (6 Weeks): 7,   Downloads (12 Months): 70,   Citation Count: 9
Additional Information:

abstract   references   cited by   index terms   collaborative colleagues  

Tools and Actions: Request Permissions Request Permissions    Review this Article  
DOI Bookmark: Use this link to bookmark this Article: http://doi.acm.org/10.1145/1173706.1173734
What is a DOI?

ABSTRACT

Tools and analyses that find bugs in software are becoming increasingly prevalent. However, even after the potential false alarms raised by such tools are dealt with, many real reported errors may go unfixed. In such cases the programmers have judged the benefit of fixing the bug to be less than the time cost of understanding and fixing it.The true utility of a bug-finding tool lies not in the number of bugs it finds but in the number of bugs it causes to be fixed.Analyses that find safety-policy violations typically give error reports as annotated backtraces or counterexamples. We propose that bug reports additionally contain a specially-constructed patch describing an example way in which the program could be modified to avoid the reported policy violation. Programmers viewing the analysis output can use such patches as guides, starting points, or as an additional way of understanding what went wrong.We present an algorithm for automatically constructing such patches given model-checking and policy information typically already produced by most such analyses. We are not aware of any previous automatic techniques for generating patches in response to safety policy violations. Our patches can suggest additional code not present in the original program, and can thus help to explain bugs related to missing program elements. In addition, our patches do not introduce any new violations of the given safety policy.To evaluate our method we performed a software engineering experiment, applying our algorithm to over 70 bug reports produced by two off-the-shelf bug-finding tools running on large Java programs. Bug reports also accompanied by patches were three times as likely to be addressed as standard bug reports.This work represents an early step toward developing new ways to report bugs and to make it easier for programmers to fix them. Even a minor increase in our ability to fix bugs would be a great increase for the quality of software.


REFERENCES

Note: OCR errors may be found in this Reference List extracted from the full text article. ACM has opted to expose the complete List rather than only correct and linked references.

 
1
 
2
A. V. Aho and T. G. Peterson. A minimum-distance error-correcting parser for context-free languages. SIAM Journal of Computation, 1(4):305--312, Dec. 1972.
3
4
 
5
6
 
7
 
8
9
 
10
H. Chen, D. Dean, and D. Wagner. Model checking one million lines of C code. In Network and Distributed System Security Symposium (NDSS), San Diego, CA, Feb. 2004.
11
12
 
13
L. Cosmides, J. Tooby, A. Montaldi, and N. Thrall. Character counts: Cheater detection is relaxed for honest individuals. In 11th Annual Meeting of the Human Behavior and Evolution Society, Salt Lake City, Utah, June 1999.
14
15
16
 
17
18
19
 
20
 
21
P. Eggert, M. Haertel, D. Hayes, R. Stallman, and L. Tower. diff - compare files line by line. In http://www.gnu.org/software/diffutils/diffutils.html, 2005.
 
22
D. Engler, B. Chelf, A. Chou, and S. Hallem. Checking system rules using system-specific, programmer-written compiler extensions. In Symposium on Operating Systems Design and Implementation, 2000.
23
 
24
D. Freedman, R. Pisani, and R. Purves. Statistics. Third edition. W. W. Norton, 1998.
 
25
G. Gigerenzer and K. Hug. Domain-specific reasoning: social contracts, cheating and perspective change. In Cognition, volume 43, pages 127--171, 1992.
 
26
A. Groce. Error explanation with distance metrics. In Lecture Notes in Computer Science, volume 2988, pages 108--122, Jan. 2004.
 
27
A. Groce and D. Kroening. Making the most of bmc counterexamples. In Electronic Notes in Theoreitcal Computer Science, volume 119, pages 67--81, 2005.
 
28
A. Groce and W. Visser. What went wrong: Explaining counterexamples. In Lecture Notes in Computer Science, volume 2648, pages 121--135, Jan. 2003.
29
30
31
 
32
33
 
34
T. Kremenek and D. Engler. Z-ranking: Using statistical analysis to counter the impact of static analysis approximations. In Static Analysis, 10th International Symposium (SAS), pages 295--315, Jan. 2003.
 
35
36
37
 
38
V. P. Ranganath, T. Amtoft, A. Banerjee, M. B. Dwyer, and J. Hatcliff. A new foundation for control-dependence and slicing for modern program structures. In European Symposium on Programming (ESOP), pages 77--93, Jan. 2005.
39
 
40
U. Shankar, K. Talwar, J. S. Foster, and D. Wagner. Detecting format string vulnerabilities with type qualifiers. In USENIX Security Symposium, pages 201--220, 2001.
 
41
42
43
44

CITED BY  9