Debugging

1
Debugging

• Chapter 5 (ALBINGs)
• Section 4.3 (ALBINGs)
• Section 4.4 (ALBINGs)

2
Debugging

• To err is human most code is not perfect, often
  far from error-free
• The java compiler catches syntactic errors
• lexical errors
• Typos such as missing
• structural errors
• e.g. without closing
• semantic errors
• int pi 3.14

3
Logical Errors

• But cant spot logical errors
• (program does not do what we want it to do)
• int myArray new int10
• for (int i 1 i lt 10 i)
• . // do some stuff
• . // do some more stuff
• Initially user stored size in location and then
  changed his/her mind without updating the loop

Here is a bug
4
Debugging

• The process of correcting mistakes in the
  thinking of the developer
• The developer could have
• formed an inaccurate mental model of the systems
  goals and constraints
• conceived of an algorithm that is incomplete or
  incorrect
• Misunderstood a programming language feature
  (e.g. inheritance) or misused a library component

5
Errors, Faults and Failures

• Errors
• The inaccurate models, misconceptions and
  misunderstandings that are in the mind of the
  programmer
• Faults (bugs)
• During development, errors manifest themselves as
  in the code which is then said to contain faults
  or bugs
• Failure
• The system, when executed, enters an unintended
  state and experiences a departure from intended
  behavior
• Errors ? Faults ? Failures
• Steps in Debugging a System

6
Steps in Debugging a System

• System failure is observed
• Corresponding faults are located in code
• Errors on the part of develop are discovered
• Once misunderstandings are identified, a correct
  model or concept can be formed (correct errors)
• Faults in the code are repaired by adding to,
  removing from and modifying the systems code
  (repair faults)
• Retest to insure failure is gone
• Insure than new changes dont introduce new
  faults into the system

7
Debugging

• The code containing a fault and code that fails
  may not be the same!
• int myArray new int1 //fault here, must be
  10
• ..........
• for (int i 0 i lt 10 i)
• sum sum myArrayi //failure here
• May have different
• Spatial relationships relationship between
  classes containing the two segments of code
• same class
• different but related classes
• unrelated classes
• Temporal relationships points in time when the
  segments of code are executed
• same method invocation
• same sequence of method invocations
• different method invocations
• How do those two types of relationships affect
  the difficult of debugging?

8
Debugging Tools

• Help they provide
• Reporting the occurrence of interesting or
  unusual events (variable initialized but never
  used)
• Providing snapshots of the system as it executes
• Allowing the developer to interrogate and control
  the systems execution
• Only for completing the first two steps in the
  debugging process
• Observe failures
• Locate faults
• Subsequent steps in debugging cant be automated
• Identifying errors
• Correcting errors
• Repairing faults

9
Debugging Tools

• To locate faults in the code, tools usually
  accumulate three different kinds of information
  about the systems execution at the point of
  failure
• The state of objects in the system at the time of
  failure
• Stack vs. heap
• Current execution sequence
• Sequence of events that immediately preceded the
  failure
• Gives an indication of the processing actions
  that were being attempted at the point of failure
• Previous execution sequence

10
Stack vs. Heap

• Memory in Java is divided into two areas, the
  stack and the heap
• On stack (in method frames)
• Primitive type variables and reference variables
  in methods
• Local variables
• Arguments passed to a function
• Returned values
• Intermediate computations
• On heap
• Objects themselves

11
Stack

• Method1 invokes Method2 which invokes Method3
• When a method returns, its frame is deleted (i.e.
  values on stack depend on the scope in which they
  were allocated

12
Heap

• Objects on the heap live independent of their
  allocation scope
• E.g., an object created inside a method, exists
  even when the execution of the method terminate
• Exist as long as there are references to them (be
  careful when using equality with
  objectsArrayList A B)
• When an object can no longer be reached from any
  pointer in the running program, it is considered
  "garbage" and ready for collection
• Garbage collection is the JVM's process of
  freeing up unused Java objects in the Java heap
• Heap size can be controlled via the -Xms and -Xmx
  command options of the java utility
• java -Xms512m -Xmx512m FileToRun
• Large heap size, full garbage collection is
  slower, but it occurs less frequently
• Small heap size, full garbage collection is
  faster, but occurs more frequently

13
Example

• public class ObjectLifetime
• StringBuffer st
• public int foo()
• / Any object created here will exist independent
  of the method, as long
• as there is still a reference to it /
• int i 8
• StringBuffer a new StringBuffer(b1")
• st a
• return i
• public static void main(String args)
• ObjectLifetime ol new ObjectLifetime()
• // call method foo, on object referenced by ol
• int k ol.foo()
• // update the value in object pointed to by ol
• ol.st.append(5")
• System.out.println("Object referenced by st
  contains " ol. st)

14
Example

• The StringBuffer object referenced by a inside
  method foo() exists even when the method returns
• This is because a reference to an object (in st
  via the st a statement), still exists outside
  the method
• As long as there are still references to an
  object, the object exists in the heap
• Local variable i defined inside the method is
  allocated in the stack, and it does not exist
  outside the method, even if the value of i is
  returned by the method
• Recall that primitive type variables are copied
  by value, while object reference variables are
  copied by reference

15

• When the ObjectLifetime code is run, it displays
  Object referenced by st contains b15