5

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.

Zarat
  • 2,584
  • 22
  • 40

3 Answers3

2

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

ams
  • 60,316
  • 68
  • 200
  • 288
  • It's a game server app, but running standalone not embedded within apache or some other framework. Most of the source is under my control. – Zarat Dec 17 '12 at 15:12
  • Thanks for the suggestions. To sum it up, from the other posts I assume there is no real equivalent to coredumps/mindumps then, and I need to look into alternatives. – Zarat Dec 17 '12 at 18:12
  • Should not require a minidump? With *any* remotely complicated system this is false and the following advice is pretty useless. You need to examine the minute internal state of a lot of objects that may not even be aware of each other when something happens; this cannot be reasonably included in an exception or a log statement. Attaching realtime to a production system is very unlikely to be feasible, only if the issue is easy to repro on a single server... minidump is the only way to go. Or would have been had Java not been a joke – Sergey Jun 02 '15 at 22:54
0

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.

Fredrik
  • 5,759
  • 2
  • 26
  • 32
  • I want to examine the arguments to the stack trace and possibly objects reachable from them. The stack trace alone just tells me what error occurred, but not what caused it. – Zarat Dec 16 '12 at 22:37
  • 1
    a heap dump will not help you at all there. I would suggest either changing the code to throw proper exception or (if it is a third party library) change to something that works as expected. If it is not for post mortem debugging at customer sites but rather in the development phase, any debugger should be enough. See @ams answer for a more detailed explanation. – Fredrik Dec 17 '12 at 15:05
  • Well, but I'd like to do 'post-mortem debugging', it's a game server app with a lot of interactions going on, so exceptions may not be obvious to reproduce a second time with a debugger attached. But thanks for the keyword, maybe I can find something under post-mortem debugging. – Zarat Dec 17 '12 at 15:17
  • If you're in control of the server. Maybe you could write an UncaughtExceptionHandler which could store as much info as possible about the current state before terminating? The first link I googled was this one http://www.javapractices.com/topic/TopicAction.do?Id=229 , it is probably old and obsolete but could serve as a starting point. – Fredrik Dec 17 '12 at 20:59
  • Well, like I already wrote, in the uncaught exception handler the stack has already been unwound, so "as much info as possible" is just the stack trace and lacking the most important thing, the arguments from the function which failed. Objects reachable through static variables don't contain any interesting information in my scenario. – Zarat Dec 17 '12 at 22:02
  • However the answer at http://stackoverflow.com/questions/314843/java-post-mortem-debugging suggests that it is possible to start/attach a debugger on uncaught exceptions - I didn't try that yet though. – Zarat Dec 17 '12 at 22:04
  • Yes, if you have one installed. In my opinion, it is as much "post mortem debugging" as having a defibrillator close when someone has a heart arrest :-). Good if you have it but unfortunately not that likely to happen. – Fredrik Dec 17 '12 at 23:01
0

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.

prunge
  • 22,460
  • 3
  • 73
  • 80
  • I had that link in my original post, so I'm aware of it, but the stack trace is already gone when the unhandled exception handler runs. Maybe heap dump really is the wrong way to solve this, but it looked like it came close to a coredump. – Zarat Dec 17 '12 at 15:15