views:

532

answers:

3
  • does java 6 generate thread dump in addition to heap dump (java_pid14941.hprof)

  • this is what happened to one of my applications.

    java.lang.OutOfMemoryError: GC overhead limit exceeded Dumping heap to java_pid14941.hprof ...

  • I did find ava_pid14941.hprof in working directory, but didn't find any file which contains thread dump. I need to know what all the threads were doing when I got this OutOfMemory error.

  • Is there any configuration option which will generate thread dump in addition to heap dump on out of memory exception?

A: 

I don't think there is anything in java that would provide you with on-exit thread dumps. I tackle this when necessary by having a cronjob that does periodic kill -3 pid. Yes, it does clutter the logs a bit, but the footprint is still negligible.

And if you are suffering from OOM, it might be be beneficial to see how the situation evolved thread-wise.

mindas
Why the downvote?
mindas
+5  A: 

How to generate thread dump java on out of memory error?

Your question can be simplified into:

  • how to generate a thread dump

and:

  • how to catch an out of memory error (don't pay attention to naysayer here, they're missing the bigger picture, see my comment)

So it's actually quite easy, you could do it like this:

  • install a default uncaught exception handler

  • upon catching an uncaught exception, check if you have an OutOfMemoryError

  • if you have an OutOfMemoryError, generate yourself a full thread dump and either ask the user to send it to you by email or offer to send it automatically

Bonus: it works fine on 1.5 too :)

 Thread.setDefaultUncaughtExceptionHandler( new Thread.UncaughtExceptionHandler() {
     public void uncaughtException( final Thread t, final Throwable e ) {
         ...
     }

You may want to look into this:

 e.getMessage();

and this:

Thread.getAllStackTraces();

I'm doing this all the time in an app that is shipped on hundreds of different 1.5 and 1.6 JVM (on different OSes).

Webinator
Note that clueless commenters/naysayers may come up with non-sense like *"you should never catch an OOM"* but they've probably never worked on Real-World [TM] Java applications being deployed on hundreds of systems. I do this **all the time** and **it just works**. This has allowed me to remotely debug and fix lots of very subtile memory leak that never ever showed up during testing. Catching an OOM here makes perfect sense **because the whole point is to understand why the OOM is happening**. But don't be surprise to see lots of naysayers here don't understanding that very basic **fact**.
Webinator
+1  A: 

If you're in a Linux/Unix environment you can do this:

-XX:OnOutOfMemoryError="kill -3 pid"

This way you don't have to have your application generate periodic thread dumps and you'll get a snapshot when it actually chokes.

Cheers,

Jim

Jim Bethancourt
Actually, it turns out that you can just load your Heap Dump generated on OOME into VisualVM and click on the "Show Threads" link under the "Threads at the heap dump" section title.
Jim Bethancourt