ACM Home Page
Please provide us with feedback. Feedback
Finding bugs is easy
Full text PdfPdf (507 KB)
Source ACM SIGPLAN Notices archive
Volume 39 ,  Issue 12  (December 2004) table of contents
COLUMN: OOPSLA onward! table of contents
Pages: 92 - 106  
Year of Publication: 2004
ISSN:0362-1340
Authors
David Hovemeyer  University of Maryland, College Park, Maryland
William Pugh  University of Maryland, College Park, Maryland
Publisher
ACM  New York, NY, USA
Bibliometrics
Downloads (6 Weeks): 44,   Downloads (12 Months): 249,   Citation Count: 33
Additional Information:

abstract   references   cited by   collaborative colleagues  

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

ABSTRACT

Many techniques have been developed over the years to automatically find bugs in software. Often, these techniques rely on formal methods and sophisticated program analysis. While these techniques are valuable, they can be difficult to apply, and they aren't always effective in finding real bugs.Bug patterns are code idioms that are often errors. We have implemented automatic detectors for a variety of bug patterns found in Java programs. In this paper, we describe how we have used bug pattern detectors to find serious bugs in several widely used Java applications and libraries. We have found that the effort required to implement a bug pattern detector tends to be low, and that even extremely simple detectors find bugs in real applications.From our experience applying bug pattern detectors to real programs, we have drawn several interesting conclusions. First, we have found that even well tested code written by experts contains a surprising number of obvious bugs. Second, Java (and similar languages) have many language features and APIs which are prone to misuse. Finally, that simple automatic techniques can be effective at countering the impact of both ordinary mistakes and misunderstood language features.


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
Apache Ant, http://ant.apache.org/, 2004.
 
3
 
4
 
5
G. Back and D. Engler. MJ: A system for constructing bug-finding analyses for Java. http://www.stanford.edu/~gback/gback-icse2004.pdf, 2003.
6
 
7
The Byte Code Engineering Library, http://jakarta.apache.org/bcel/, 2004.
 
8
 
9
 
10
CheckStyle, http://checkstyle.sourceforge.net, 2004.
11
12
 
13
R. F. Crew. ASTLOG: A language for examining abstract syntax trees. In USENIX Conference on Domain Specific Languages, pages 229--241, Santa Barbara, 1997.
 
14
M. C. Daconta, E. Monk, J. P. Keller, and K. Bohnenberger. Java Pitfalls. John Wiley & Sons, Inc., 2000.
15
 
16
DrJava, http://www.drjava.org/, 2004.
 
17
A. Druin, B. Bederson, A. Weeks, A. Farber, J. Grosjean, M. Guha, J. Hourcade, J. Lee, S. Liao, K. Reuter, A. Rose, Y. Takayama, L., and L. Zhang. The international children's digital library: Description and analysis of first use. Technical Report HCIL-2003-02, Human-Computer Interaction Lab, Univ. of Maryland, January 2003.
 
18
Eclipse, http://www.eclipse.org/, 2004.
19
 
20
D. Engler, B. Chelf, A. Chou, and S. Hallem. Checking system rules using system-specific, programmer-written compiler extensions. In Proceedings of the Fourth Symposium on Operating Systems Design and Implementation, San Diego, CA, Oct. 2000.
 
21
22
23
24
25
26
 
27
GNU Classpath, http://www.gnu.org/software/classpath/, 2004.
28
29
 
30
D. Hovemeyer and W. Pugh. Finding concurrency bugs in Java. In Proceedings of the PODC Workshop on Concurrency and Synchronization in Java Programs, St. John's, Newfoundland, Canada, July 2004.
 
31
Java(tm) 2 Platform, Standard Edition, http://java.sun.com/j2se/, 2004.
 
32
Collected java practices. http://www.javapractices.com.
 
33
JBoss, http://www.jboss.org/, 2004.
 
34
jEdit, http://www.jedit.org/, 2004.
 
35
S. Johnson, Lint, a C program checker. In UNIX Programmer's Supplementary Documents Volume 1 (PS1), April 1986.
 
36
T. Kremenek and D. R. Engler. Z-ranking: Using statistical analysis to counter the impact of static analysis approximations. In Proceedings of Static Analysis, 10th International Symposium, SAS 2003, San Diego, CA, USA, pages 295--315, June 2003.
37
 
38
PMD, http://pmd.sourceforge.net, 2004.
 
39
W. Pugh. The double checked locking is broken declaration. http://www.cs.umd.edu/users/pugh/java/memory-Model/DoubleCheckedLocking.html, July 2000.
 
40
41
 
42
 
43
U. Shankar, K. Talwar, J. S. Foster, and D. Wagner. Detecting format string vulnerabilities with type qualifiers. In Proceedings of the 10th Usenix Security Symposium, Washington, D.C., Aug. 2001.
 
44
N. Sterling. WARLOCK --- a static data race analysis tool. In Proceedings of the USENIX Annual Technical Conference, pages 97--106, Winter 1993.
 
45
46

CITED BY  33
Collaborative Colleagues:
David Hovemeyer: colleagues
William Pugh: colleagues