debugging tools
TRANSCRIPT
DEBUGGING TOOLS MOHAMED ALI KHASKIA && MOHAMED MABROUK MAWD
1. COMMAND LINE DEBUGGERS
1. COMMAND LINE DEBUGGERS Main tools: The main actor here is jdb, which comes with the JDK and is the JVM equivalent of gdb. It has a command line interface, and can be attached to a running JVM. Like gdb, its functionality is robust and you can pretty much do anything with jdb that you could with a full blown IDE debugger. jdb has a sidekick – jstack – which lets you print the thread call stacks of a live JVM at a given moment. This however does not capture variable or heap state.
1. COMMAND LINE DEBUGGERS
Used when: jdb’s biggest upside is its portability. You could get it onto a server fairly quickly without having to attach a debugger remotely. If you’re dealing with a nasty situation on a server and can afford to stall the JVM to inspect it, jdb is your best friend
1. COMMAND LINE DEBUGGERS
Disadvantage: The downside with jdb and jstack is that, as with other command line tools, they’re not very productive for everyday use. That brings us to our next category.
2. IDE DEBUGGERS
2. IDE DEBUGGERS
• Main tools: In this category two tools lead the pack today – Eclipse and NetBeans. Both use a similar technology as jdb to either attach to or launch a new JVM. While not very portable, you do get all the bells and whistles, which can make debugging shorter and a whole lot more fun. • Disadvantage: As high end desktop applications, they’re not
something you’ll want to run on a production machine. There’s always the possibility of remote debugging, but in complex environments, chances of that working out are slim
3. BUILD YOUR OWN DEBUGGER
3. BUILD YOUR OWN DEBUGGER
• All the debuggers we’ve described so far are built on the same JVM open debugging architecture, most commonly using the JDWP (Java Debugger Wire Protocol) to communicate with a running JVM. JSwat is an example of a standalone debugger built on top of this framework. Want to learn how to build your own Java/Scala debugger?
Visit• http://blog.takipi.com/how-to-write-your-own-java-scala-
debugger/
3. BUILD YOUR OWN DEBUGGER
• Used when: Building a custom JVM extension, or having a very keen interest in how the JVM works. • Disadvantage: This is fairly complex stuff to get right
(especially as you don’t want to affect the state of the target JVM), so you need a very compelling reason as to why you can’t use an existing, battle-tested tool.
4. HEAP DUMPS
4. HEAP DUMPS
Main tools: jmap, MAT. In many cases, just like Rick Grimes, you’re dealing with the deceased. In these cases you’re looking at a snapshot of a JVM heap, rather than that of a live JVM that’s been stalled. jmap, which comes with the JDK, lets you generate heap dumps from a live JVM. There are a number of tools out there that can then let you explore and analyze the dump. Used when: A complex error occurs and normal debugging techniques can’t be applied Another option is to use heap dumps to analyze memory leaks
5. HISTORICAL DEBUGGERS
6. DYNAMIC TRACING
7. PRODUCTION DEBUGGING