Finding Bugs Is Easy

1
Finding Bugs Is Easy

• David Hovemeyer and William Pugh
• Department of Computer Science
• University of Maryland, Collage Park

Presented by Guy Linksman
2
Measuring is Hard

• Easy to evaluate research that attempts to
  improve the speed of standard benchmark programs
• Hard to evaluate
• Better programming languages/methods
• Program understanding tools
• Formal methods for specification
• Bug finding tools

3
A Taxonomy of Bug FindingTools

• Static/Dynamic
• Kinds of bugs
• Accuracy

4
Bug Finding Tools

• Static tools
• Look at program without requiring execution
• Covers all program paths
• Hard to be accurate, considers infeasible paths
• Dynamic tools
• look for errors that occur in a particular run
• dont look for errors in untested paths

5
Bug Finding Tools

• Check against language semantics
• - access outside bounds of an array
• Check against application specification
• specifications are rare and frequently
  incorrect or incomplete
• Check against bug patterns
• a commonly occurring pattern that is
  frequently erroneous

6
Bug Finding Tools

• No false positives
• - All problem reports correspond to real
  problems
• No false negatives
• Finds all problems
• Perfect
• No false positives or negatives
• Best effort
• No guarantees

7
Typical Approach

• Typical research approach
• Hypothesize that a technique would be useful
• Work out the details
• Implement it
• Try to demonstrate the usefulness of it
• Find three bugs in production code

8
Bugs can be hard to find

• Lots of work recently on dynamic data
• race detection tools
• collect data so as identify synchronization
  errors that occurred during an execution
• Few well documented test cases in real code to
  test these tools on
• bug databases are typically of little use

9
Bugs driven research

• Work from bugs to tools
• When we come across bugs or bug patterns
• -in student code
• - bug reports
• - books and articles
• Try to figure out how to capture them in a tool

10
New approach

• Incremental and iterative approach
• Come up with quick and dirty bug detector
• Evaluate it on some applications, evaluate the
  reports it generates
• has to catch some real problems
• not have too high of a false positive rate
• tune or discard

11
Test Cases
Suns J2SE 1.4.1
GNU classpath
ICDL
Tomcat Webserver
12
Correctness issues

• Bad co-variant definition of equals
• Class defined with equals taking argument other
  than Object
• uses default version of equals(Object) defined in
  class Object

class Foo public boolean equals (Foo o)

13
Correctness issues

• Equal objects must have equal hashcodes
• For hashtables to work, any two equal objects
  must wind up in same bucket
• must have equal hashcodes
• Check to see if a class redefines equals but uses
  the default implementation of hashCode defined in
  class Object

14
Correctness issues

• Redefine hashCode but not equals
• Doesnt break hashCode/equals contract
• But likely to be a problem

15
Correctness issues

• Incorrect use of finalizers
• Define a public finalize method
• Defined as protected in class Object
• Inappropriately grants access to anyone
• Doesnt call super.finalize()
• finalizer code in superclass doesnt get
  invoked
• Empty/useless finalize methods

16
Correctness issues

• Return value of read ignored
• read methods that read into an array
• return the number of bytes actually read
• may not read all the bytes buffer could hold
  
• Reads over the network can be short
• as many bytes as are in a this packet
• Ignoring the return value could be a mistake

17
Correctness issues

• int length input.readInt()
• byte byteArray new bytelength
• input.read(byteArray, 0, length)

Fine tuning
18
Correctness issues

• Field read before being initialized
• A field is read within the constructor before it
  could possibly have been initialized
• compiler already checks that local variables
  are initialized
• hard to check outside of constructor
• you dont know which order methods would be
  invoked in

19
Correctness issues

• public final class AccessControlContext
• private ProtectionDomain protectionDomain
• public AccessControlContext(ProtectionDomaincon
  text) // remove duplicates from context
• int i, k, count context.length, count2 0
• for (i 0 i lt count i)
• for (k 0 k lt i k)
• if (contextk protectionDomaini) break
• if (k ! i) continue
• count2 // count of unique entries

20
Correctness issues

• // java.awt.image.SampleModel, v 1.3.1
• public abstract class SampleModel
• protected int width, height
• public SampleModel(int dataType, int w, int h,
  int numBands)
• if (w lt 0 h lt 0)
• throw new IllegalArgumentException(
• "Width ("w ") and height ("height ") must
  be gt 0")

21
Multithreaded CorrectnessIssues

• Spin Waiting
• A thread has a loop that waits for a variable to
  be changed
• no synchronization in loop
• Bad
• uses lots of CPU cycles
• compiler may hoist read out of loop

22
Multithreaded CorrectnessIssues

• public class DatabaseInteractor implements
  Runnable
• // lock for lists
• private boolean listlock false
• public synchronized void
• runQueryInSeparateThread()
• while (listlock)
• listlock true

23
Multithreaded CorrectnessIssues

• private boolean processingRequest
• public ResultSet runQuery(String querystring)
• while (processingRequest)
• processingRequest true
• resultSet executeHTTPQuery(querystring)
• processingRequest false
• return resultSet

24
Multithreaded CorrectnessIssues

• Inconsistent synchronization
• Ignored
• public fields
• volatile fields
• fields that are never read without a lock.
• fields with high proportion of unlocked accesses.

25
Multithreaded CorrectnessIssues

• wait not in a loop
• It is possible to use wait() without a loop, but

26
Multithreaded CorrectnessIssues

• Unconditional wait / notify
• Java uses wait and notify/notifyAll to allow
  threads to wait for conditions to become ready
• Bug is to
• check if ready
• if not, get the lock and wait until notified

27
Multithreaded CorrectnessIssues

• // International Childrens Digital Library
• if (!book.isReady())
• DebugInfo.println("book not ready")
• try
• synchronized (book)
• DebugInfo.println("waiting")
• book.wait()

28
Multithreaded CorrectnessIssues

• Problem
• the book can become ready between check and
  acquiring the lock
• Since notify is only done when book becomes ready
  waiter is never notified

29
Vulnerability to untrustedand/or malicious code

• Returning a reference to an internal array
• method returns a reference to an array which is
  still part of the internal representation of the
  class
• caller can
• see changes to the array
• make their own changes to the array

30
Vulnerability to untrustedand/or malicious code

• //j2se 1.4.1
• public class JarEntry extends ZipEntry
• Certificate certs
• public Certificate
• getCertificates
• return certs

31
Vulnerability to untrustedand/or malicious code

• Mutable static variables
• Can static fields be modified by untrusted code?
• public, non-final static fields
• public static fields that reference an array
• public static methods that return a reference to
  a static array

32
Vulnerability to untrustedand/or malicious code

• // Suns J2SE 1.4.1
• public class JPEG // Names of the formats
  we can read or write
• public static final String names
  "JPEG", "jpeg", "JPG", "jpg"

33
Performance issues

• Unused and unread fields
• May be vestigial, left over from earlier code
• performance hit?
• May be a mistake
• was supposed to have been used, but because
  of a mistake was not

34
Performance issues

• Fields that should be static
• A final field that is always initialized to a
  constant
• making it static will reduce the size of objects

35
Performance issues

• // Suns J2SE 1.4.1
• final class MergeCollation
• private final byte ITARRAYMASK(byte)0x1
• private final int BYTEPOWER 3
• private final int BYTEMASK (1ltltBYTEPOWER) -1

36
Implementation

• Code insensitive
• Flow insensitive
• Flow sensitive
• CFG-based

37
Sum up

• Need different detectors for students
• Students made a lot of mistakes that werent
  checked for by tool
• performing wait/notify while holding lock
  on wrong object
• not starting any threads in their
  multithreaded programming
• project
• Some detectors appropriate for students may
  generate too many false positives for
  professional programmers

38

• The End