Java equivalent of coredump on uncaught exception

Question

What is the Java equivalent of a Linux coredump or Windows minidump? I've read about heap dumps and it looks like what I want, but how to trigger them (automatically) on uncaught exceptions?

I know about the uncaught exception handler and I'm already using it to print the exception + stack trace and terminate the whole application (otherwise the thread dies and the application keeps running? huh?) Also I found this post about how to record heap dumps from code, but if I do that from the unhandled exception handler Java already has caught the exception and the stack trace (and arguments) are gone.

I came across the -XX:+HeapDumpOnOutOfMemoryError flag which seems to do what I need, unfortunately only for out of memory exceptions and not for other uncaught exceptions.

That's the only things I've been able to get out of google so far. Currently I'm using an attached debugger with exception breakpoints, but that is impractical because it also breaks on handled exceptions, so it can't be used unsupervised.

[update on motivation]

I want to be able to examine the arguments and local variables of the stack trace to figure out what caused the exception. Its usually null reference exceptions or assertions that fail, and I cannot always guess from the line number what exactly went wrong. In C/C++ I'm used to crash with a coredump/minidump and then examine further what has actually led to the crash.

Answer 1

If you are not doing JNI and calling out to native code it is pretty hard to corrupt the JVM's memory, exceptions should not require a heap dump or a core dump.

In the java world the code throwing the exception is expected to provide enough information for some one reading the exception to be able to determine the cause of the problem. Some times this does not happen and the right way to deal with it is to modify the exception throwing code to provide more info in the exception or log something to a log file.

If the code throwing the exception is not under your control and you don't have access to the source code, then you can use something an AspectJ to weave some around advice to the method throws the exception then you can examine the function arguments in the aspect and log them. But before you the route aspectJ / byte code weaving you might want to see if the code you trying to understand uses log4j or some other logging framework that has a debug logging level, that might hive the info you are looking for.

You might want to take a look at the Google Guava Open Source Library it has a nice section on Pre conidtions which you can use to validate arguments and get more context about the cause of problems. http://code.google.com/p/guava-libraries/wiki/PreconditionsExplained

You wight also want to look at http://www.slf4j.org/ which has a good logging api that you can use to log information about the problems you are running into it.

You can also do conditional break points in eclipse, this allows you to have the breakpoint execute only under certain circumstance. http://wiki.eclipse.org/FAQ_How_do_I_set_a_conditional_breakpoint%3F

Another tool to use is jvisiual vm which allow you to connect to a live vm and find out a lot information about what is going on inside the vm like where all the threads are, if any are deadlockers, what the GC is doing, and you can trigger heapdumps with it then query them and look at the state of specific objects in the heap dump. http://docs.oracle.com/javase/7/docs/technotes/guides/visualvm/index.html

Answer 2

I don't think a heap dump is what you are looking for. It is just a dump of the heap and the reason to turn on that switch is that if you get an OOM exception, the one thing you probably want to investigate is what the memory was used for so that you can find your leak (or other problem).

That exactly is it you want to use them for? Maybe there is an alternative but better way to address your needs in java. I don't think I have ever had a need for anything like a core or minidump from java. Except maybe for situations where I wish there was a way to call abort() just to be able to study how the code ended up where it did.

Answer 3

This blog from Oracle describes how to programatically do a heap dump:

https://blogs.oracle.com/sundararajan/entry/programmatically_dumping_heap_from_java

It essentially uses Hotspot's com.sun.management.HotSpotDiagnosticMXBean and its dumpHeap() method. It will probably only work with Oracle/Sun JVMs and no guarantees it will work in the distant future.

The hard part, however, is once you have this heap dump how to get useful information out of it. I'd imagine you'd start by finding the freshly thrown exception object and go from there. What the heap dump won't help you with the method arguments and local variable values as primitives and references wont be present in the heap dump.