When a JVM crashes (segfaults) during garbage collection, how can I find out what was being collected?

Question

I get segfaults in my JVM at roughly the same phase of the application, but with varying stack traces in the crash report. It always seems to happen during GC, however.

Since the crash happens in all three JVMs I tried (OpenJDK 6, Oracle 1.6.0_25 and 1.7.0) and with two GCs each (Parallel Collector and CMS), and it happens around the same area in the application, I figured, if I could find what the GC was trying to collect, I might spot some peculiarity in my code that causes this crash.

• Are there any coding practices that are well known to be problematic for GC?
• What methods are available for diagnosing this problem?
• Can I make any educated guesses on where in my application this problem is triggered?
• What (GC tuning) parameters can I play with to narrow the problem down?
• Is there a way to spot (possibly) problematic data in a heap dump?

Answer 1

• seg faults have specific error codes at the beginning of the dump http://en.wikipedia.org/wiki/Segmentation_fault

• You can use Thread.dumpStackTrace to see what is going on in that application If you know exactly where your application is freezing or going to freeze after a certain action or event you can CTRL + break windows or CTRL + \ to get a thread dump and see what is going on.

• Instead of vaguely guessing you can comment out certain sections of the code to find out which loop or object or buffer or string is taking too long

• depending upon your situation you can consider some specific tools.

Answer 2

This will happen if you have JNI library which handles memory incorrectly. The problem does not show immediately. However when a GC is performed, it scans all the memory, trips over the corrupted reference and kills the JVM. i.e. the corruption could have occurred at any time since the last Full GC.