Java Debugging & Profiling Techniques - PowerPoint PPT Presentation

java debugging profiling techniques n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Java Debugging & Profiling Techniques PowerPoint Presentation
Download Presentation
Java Debugging & Profiling Techniques

play fullscreen
1 / 85
Java Debugging & Profiling Techniques
199 Views
Download Presentation
preston-hays
Download Presentation

Java Debugging & Profiling Techniques

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. JavaDebugging & ProfilingTechniques Ethan Henry egh@klg.com KL Group http://www.klgroup.com

  2. Overview This session will touch on three major topics: • Debugging and • Profiling plus • Memory Leaks in Java

  3. Debugging • What’s debugging? • If you don’t already know… • Debugging is the process of finding errors in your software, regardless of what kind of errors they are

  4. Types of Errors • Program errors can be lumped into one of three broad categories: • syntactic errors • static errors • dynamic errors • Syntactic errors are the easiest to find, dynamic errors are the most difficult

  5. Syntactic Errors • A syntactic error is one in which the program is ill-formed by the standard of the programming language • e.g. a keyword is misspelled • Syntactic errors are trivial to detect and correct • the compiler does the detection for you • which is one reason compiled languages are so popular

  6. Static Errors • Static errors are ones in which the program is syntactically correct but semantically incorrect • For example, substituting a “>” for a “<” • Static errors can be very difficult to detect but are usually quite obvious • Java’s exception mechanism helps deal with these types of errors

  7. Dynamic Errors • The dynamic error is the most insidious kind of errors • Dynamic errors occur in code which is both semantically and syntactically correct but where implicit assumptions have been violated • The prevention of dynamic errors is a major focus of software engineering

  8. Dynamic Errors • An example of a dynamic error: • the most dramatic example I could find • The Ariane 5 crash on June 4, 1996 was due to a reuse error • reuse of an inertial reference system software component caused a 64-bit integer to be incorrectly converted into a 16-bit unsigned integer, causing an exception that went uncaught and crashed the guidance system • http://www.eiffel.com/doc/manuals/technology/contract/ariane/index.html

  9. Debugging Techniques • Debugging is an art as old as programming is, so there are a lot of approaches to it • For Java, we can divide debugging techniques into two categories: • “Classic” • Java-specific

  10. Classic Debugging Techniques • print statements • assert

  11. Jurassic Debugging • println statements • System.out.println • connected to the standard output stream • System.err.println • connected to the standard error stream • both are instances of java.io.PrintStream • helps with static & dynamic errors • difficult to deal with in general

  12. toString() • The one very useful thing about using println to debug is that every object has a toString() method • inherited from Java.lang.Object • This means that you can always do things like this: Frame f = new Frame(“Main App”);System.out.println(“The frame info is “+f);

  13. toString() • By default, toString() just prints out an object identifier, so you should override it in your own classes • Tip: The first thing you should do in a toString method is create a StringBuffer to hold the data you’re printing

  14. Using println • How can you make debugging statements easier to deal with? • Conditional code • via if • via a pre-processor • a debugging class

  15. Using println • If use an expression that’s constant at compile time, if statements act like conditional code and will be evaluated at compile time static final boolean DEBUG = true; // or false … if(DEBUG) { System.out.println(“Some message”); }

  16. Using println • Another option is to use an actual pre-processor, like in C/C++ • cpp, perl, m4, tcl - any general scripting language should work • This is more complex, but is marginal extra work in a large project • Advantage over using if: • you can completely strip out the debugging code if you want

  17. Using println • Another technique is to use a class that logs errors • typically a singleton • For example:

  18. import java.io.*; public final class Log { private static Log log; private PrintStream stream; private boolean printing; private Log() { stream = System.out; printing = true; } static { log = new Log(); } public static Log getLog() { return log; }

  19. public void setPrinting(boolean b) { printing = b; } public void setStream(OutputStream os) { if(os instanceof PrintStream) stream = (PrintStream)os; else stream = new PrintStream(os); } public void println(String msg) { if(printing) stream.println(msg); } public void print(String msg) { if(printing) stream.print(msg); } }

  20. Assert • Assert is a classic C & C++ programming construct • Assert statements are used to verify various conditions in program code • Very useful for detecting dynamic errors • For example: public int doThing(int x) { Assert.assert(x > 0); // do some things... }

  21. Assert • While the C assert stops the program, a Java assert would be better off doing something less intrusive, like throwing a RuntimeException • There is an example of a full assert package (JContracts) at: • http://www.halcyon.com/nickx/JContracts/ • There’s a JSR on the subject as well: • http://java.sun.com/aboutJava/communityprocess/jsr/jsr_041_asrt.html

  22. A sample assert class public final class Assert { // change to false if you want to disable assertions private final static boolean ENFORCE = true; public static void assert(boolean b) { if(ENFORCE && (b == false)) throw new RuntimeException("assertion violated"); } }

  23. Java-Specific Techniques • Exception Handling • Reading Exception Messages • Thread Dumps

  24. Exception Handling • An exception is “thrown” when some unexpected condition occurs at runtime • Only instances of java.lang.Throwable (or a subclass) can be thrown by the throw statement • Throwable has two subclasses: • java.lang.Error • java.lang.Exception

  25. Errors • Error objects are thrown by the virtual machine or Java library to indicate a serious problem • Most applications shouldn’t try to catch or throw an Error object • The predefined errors are:

  26. java.awt.AWTError java.lang.LinkageError java.lang.ClassCircularityError java.lang.ClassFormatError java.lang.ExceptionInInitializerError java.lang.IncompatibleClassChangeError java.lang.AbstractMethodError java.lang.IllegalAccessError java.lang.InstantiationError java.lang.NoSuchFieldError java.lang.NoSuchMethodError java.lang.NoClassDefFoundError java.lang.UnsatisfiedLinkError java.lang.VerifyError java.lang.ThreadDeath java.lang.VirtualMachineError java.lang.InternalError java.lang.OutOfMemoryError java.lang.StackOverflowError java.lang.UnknownError Errors

  27. Exceptions • An exception indicates some sort of problem that a typical application might want to deal with • There are two types of exceptions: • checked exceptions • unchecked exceptions

  28. Checked Exceptions • Direct subclasses of java.lang.Exception represent exceptions that the developer must deal with • These exceptions can only be thrown if declared in the throws clause of the method • Any code calling a method that throws a regular exception must catch it and deal with it

  29. Checked Exceptions • Some examples of checked exceptions are: • java.lang.ClassNotFoundException • thrown by Class.forName() • java.io.IOException • thrown by many I/O operations • java.lang.IllegalAccessException • thrown by Class.newInstance() • java.lang.InterruptedException • thrown by sleep and wait

  30. Unchecked Exceptions • Unchecked exceptions need not be declared in the throws clause of a method and do not need to be caught • These are exceptions that are too frequent to check for every time • Unchecked exceptions are derived from java.lang.RuntimeException instead of java.lang.Exception • RuntimeException is derived from Exception though

  31. Unchecked Exceptions • Some example of unchecked exceptions: • java.lang.ArithmeticException • java.lang.ClassCastException • java.lang.IllegalArgumentException • java.lang.NumberFormatException • java.lang.ArrayIndexOutOfBoundsException • java.lang.StringIndexOutOfBoundsException • java.lang.NegativeArraySizeException • java.lang.NullPointerException

  32. Handling Exceptions • Exceptions are dealt with via the throw, try, catch and finally keywords • The code that encounters a problem creates an exception by instantiating some exception object and throwing it throw new SomeBadException(“some message”);

  33. Handling Exceptions • The exception then unwinds the stack of the thread it was thrown in, looking for a try block • If there is a catch associated with the try block that matches the type of the exception, the catch block is executed • After the catch block executes (or if no exception was thrown) the finally block associated with the try block is executed

  34. Handling Exceptions • If no handler is found, the current thread’s ThreadGroup’s uncaughtException(Thread,Throwable) method is called • if there is a parent ThreadGroup, pass it the exception • otherwise print the exception stack trace to System.err

  35. Handling Exceptions import java.io.IOException; public class Exception { public static void main(String args[]) { try { foo(args[0]); System.out.println("whew"); } catch(IOException e) { System.out.println("doh!"); } finally { System.out.println("finally..."); } System.out.println("done!"); }

  36. Handling Exceptions public static void foo(String s) throws IOException { if(s.equals("checked")) { throw new IOException("Checked"); } else if(s.equals("unchecked")) { throw new RuntimeException("Unchecked"); } System.out.println("No exception"); } }

  37. Reading Exception Messages • A typical exception stack trace looks something like this: • from a modified version of the ‘Fractal’ example that comes with the JDK java.lang.NullPointerException at ContextLSystem.<init>(CLSFractal.java:319) at CLSFractal.init(CLSFractal.java:66) at sun.applet.AppletPanel.run(AppletPanel.java:287) at java.lang.Thread.run(Thread.java:474)

  38. Reading Exception Messages • Information shown: • the type of exception java.lang.NullPointerException • the class & method in which the exception was thrown at ContextLSystem.<init>(CLSFractal.java:319) • the full stack trace for the thread executing the code at that point at CLSFractal.init(CLSFractal.java:66) at sun.applet.AppletPanel.run(AppletPanel.java:287) at java.lang.Thread.run(Thread.java:474) • Note that line numbers are not shown if a JIT is being used

  39. Reading Exception Messages • There are two special methods that aren’t identified by their human-readable names: • <init> • a constructor • <clinit> • the static “class constructor” code block

  40. The “Magic Thread Dump Key” • Windows: Ctrl-Break • Solaris: Ctrl-\ or kill -QUIT [pid] • A sample thread dump • How to read a thread dump • Diagnosing deadlock

  41. A Sample Thread Dump From a sample application: Full thread dump Classic VM (JDK-1.2-V, native threads): "Thread-0" (TID:0x1915a28, sys_thread_t:0x8ebd60, state:CW, native ID:0x113) prio=5 "AWT-Windows" (TID:0x1916ce0, sys_thread_t:0x8a6410, state:R, native ID:0x10a) prio=5 at sun.awt.windows.WToolkit.eventLoop(Native Method) at sun.awt.windows.WToolkit.run(WToolkit.java:134) at java.lang.Thread.run(Thread.java:479) "SunToolkit.PostEventQueue-0" (TID:0x1916e10, sys_thread_t:0x8a5b70, state:CW, native ID:0x103) prio=5 at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Compiled Code) at sun.awt.PostEventQueue.run(SunToolkit.java:363) "AWT-EventQueue-0" (TID:0x1916de0, sys_thread_t:0x8a3680, state:CW, native ID:0x10d) prio=6 at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Compiled Code) at java.awt.EventQueue.getNextEvent(EventQueue.java:179) at java.awt.EventDispatchThread.run(EventDispatchThread.java:67) "Finalizer" (TID:0x18f9320, sys_thread_t:0x8209d0, state:CW, native ID:0x116) prio=8 at java.lang.Object.wait(Native Method) at java.lang.ref.ReferenceQueue.remove(Compiled Code) at java.lang.ref.ReferenceQueue.remove(Compiled Code) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:174)

  42. A Sample Thread Dump "Reference Handler" (TID:0x18f93b0, sys_thread_t:0x81fdc0, state:CW, native ID:0x10f) prio=10 at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Compiled Code) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:114) "Signal dispatcher" (TID:0x18f93e0, sys_thread_t:0x81f560, state:R, native ID:0x117) prio=5 Monitor Cache Dump: sun.awt.PostEventQueue@1916E10/1957BC0: <unowned> Waiting to be notified: "SunToolkit.PostEventQueue-0" (0x8a5b70) java.awt.EventQueue@1916D90/19579B8: <unowned> Waiting to be notified: "AWT-EventQueue-0" (0x8a3680) java.lang.ref.ReferenceQueue$Lock@18F9338/192ED78: <unowned> Waiting to be notified: "Finalizer" (0x8209d0) java.lang.ref.Reference$Lock@18F93C0/192E8A8: <unowned> Waiting to be notified: "Reference Handler" (0x81fdc0)

  43. A Sample Thread Dump Registered Monitor Dump: Invoker change lock: <unowned> utf8 hash table: <unowned> JNI pinning lock: <unowned> JNI global reference lock: <unowned> BinClass lock: <unowned> Class linking lock: <unowned> System class loader lock: <unowned> Code rewrite lock: <unowned> Heap lock: <unowned> Monitor cache lock: owner "Signal dispatcher" (0x81f560) 1 entry Thread queue lock: owner "Signal dispatcher" (0x81f560) 1 entry Waiting to be notified: "Thread-0" (0x8ebd60) Monitor registry: owner "Signal dispatcher" (0x81f560) 1 entry

  44. How to Read a Thread Dump • The thread dump contains the following information: • a listing of all the threads running in the VM • including a full stack dump if available • plus the native thread id, priority and current thread state • a list of all monitors that have been created • including the current owner and the number of threads waiting for that monitor to be released • a list of all “special” monitors • these are used by the VM internally

  45. Thread States • Each thread has a state associated with it: • R Running or runnable thread • S Suspended thread • CW Thread waiting on a condition variable • MW Thread waiting on a monitor lock • MS Thread suspended waiting on a monitor lock • You should never see a thread in the ‘MS’ state • if you do, there’s a good chance it’s a VM bug

  46. More on Thread Dumps • The JDC has a very nice, detailed description of what each element in the thread dump is: • http://developer.java.sun.com/developer/technicalArticles/Programming/Stacktrace • This includes details on what each of the internal monitors are for and more • It’s for JDK 1.1, but should be helpful for JDK 1.2 as well

  47. Other Magic Keys • Related to the “Magic Thread Dump” key is the “Magic AWT Dump” key • Ctrl+Shift+F1 • the code for this is hidden away inside java.awt.Window of all places • Magic Netscape Console Keys • hit ? in the Navigator Java console to get the list of commands

  48. Interactive Debuggers • Free: • jdb • JBuilder Foundation (IDE) • http://www.borland.com/jbuilder • NetBeans Developer/Forte for Java (IDE) • http://www.netbeans.com • Commercial: • Metamata Debug • http://www.metamata.com • Karmira BugSeeker • http://www.karmira.com

  49. JDK 1.0/1.1 Debugging API • The Java VMs in JDK 1.0 and JDK 1.1 support a basic remote debugging API • A remote agent is built into the Java VM which can be accessed over a socket via the RemoteDebugger class • Most of this API has never been formally published

  50. JDK 1.0/1.1 Debugging API • The basic debugger architecture: h Java Interpreter JavaVM Agent Request Reply Instance ofRemoteDebugger Java DebuggingClient