Is it possible to have a post-mortem ( or post-exception ) debugging session in Java ? What would the workarounds be ( if there isn't a solution for this already ) ?
+3
A:
You can attach the debugger to a java process and set a breakpoint when a specific exception is received. Is this what you need?
From http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/jdb.html
When an exception occurs for which there isn't a catch statement anywhere up a Java program's stack, the Java runtime normally dumps an exception trace and exits. When running under jdb, however, that exception is treated as a non-recoverable breakpoint, and jdb stops at the offending instruction. If that class was compiled with the -g option, instance and local variables can be printed to determine the cause of the exception.
This type of breakpoints can be set with any IDE, such as Eclipse. Using eclipse you can also set a breakpoint on a specific exception type, even if it is caught in the normal code.
If you have something like a multi-threaded server running, and one of the threads servicing a client throws an unhandled exception, then you would be able to check the debugger and see what happens. I don't think this is something for production, but definitively helps when testing.
The application does not have to run from the debugger, but it can be launched with the debug options as arguments:
-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=XXXX
The application runs normally, but switches into "interpreted" mode when a breakpoint is hit, at least in more modern versions of the JVM. So the performance is not affected.
In this link, check the section about "full-speed debugging for HotSpot VM"
Full Speed Debugging
The Java HotSpot VM now uses full-speed debugging. In previous version of the VM, when debugging was enabled, the program executed using only the interpreter. Now, the full performance advantage of HotSpot technology is available to programs, even with compiled code. The improved performance allows long-running programs to be more easily debugged. It also allows testing to proceed at full speed. Once there is an exception, the debugger launches with full visibility to code sources.
Mario Ortegón
2008-11-24 17:52:01
The thing is that my application will run for an undeterminate period of time , and if it will throw an exception , I would like to debug . The thing is that if I run the application in the debugger , the performance will degrade .
Geo
2008-11-24 17:54:38
I've expanded the info on full speed debugging.
Mario Ortegón
2008-11-24 18:01:06
+3
A:
As far as I know, you'd have to wait for Java 7 for an official API - see http://tech.puredanger.com/java7#jsr326.
In the meantime, you could substitute Exception (replace base class, inject code via instrumentation, etc) to keep your data. Please note though the ClassLoader throws and catches ClassNotFoundException regularly (each new package loaded). You'd have a lot of control that way without having to modify you base code.
Ran Biron
2008-11-24 17:58:37
While there are many words in common, JSR 326 doesn't (AFAIK) address the question that was asked. Rather, it establishes standard formats and tools for reading artifacts produced from Java programs (heap dumps, stack traces, etc). I don't see how that would let you actually debug post-mortem.
Alex Miller
2008-11-24 21:04:41
@alex I must have assumed that by "debugging post moretem" Charade meant going over the heap / getting an accurate stack trace instant before jvm death. You're right - it doesn't really answer the question.
Ran Biron
2008-12-15 05:58:17
+1
A:
I'm a Solutions Architect for Replay Solutions. They provide a "time machine" for java applications. You can record an application while it's running (let's say, in a QA environment), then replay the recording on your development machine. You do not need access to the database, configurations, etc. All you need is their ReplayDIRECTOR solution and you can debug the problem in the friendly confines of your IDE. Problems that can be replayed range from configuration issues, database exceptions to threading problems. Take a look: