JDK-6754987 : Crash triggering Heapdump via -XX:+HeapDumpOnCtrlBreak AND -XX:+UseParallelOldGC
  • Type: Bug
  • Component: core-svc
  • Sub-Component: tools
  • Affected Version: 5.0,5.0u16
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_2.5.1,windows_vista
  • CPU: x86,sparc
  • Submitted: 2008-10-01
  • Updated: 2011-03-01
  • Resolved: 2009-03-24
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
5.0u19 b01Fixed
Description
OPERATING SYSTEM(S):
All

FULL JDK VERSION(S):
java version "1.5.0_16"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_16-b02)
Java HotSpot(TM) Server VM (build 1.5.0_16-b02, mixed mode)

DESCRIPTION:
With -XX:+UseParallelOldGC enabled, the VM crashes when triggering a heapdump via the HeapDumpOnCtrlBreak functionality.

  To reproduce, run any java program with the options -XX:+UseParallelOldGC and -XX:+HeapDumpOnCtrlBreak, and attempt to gather a heapdump (e.g. on Solaris, send a kill -3 to the process).

You will see this error:

#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
#  SIGSEGV (0xb) at pc=0xfe4583a4, pid=2704, tid=6
#
# Java VM: Java HotSpot(TM) Client VM (1.5.0_16-b02 mixed mode)
# Problematic frame:
# V  [libjvm.so+0x4583a4]
#
# An error report file with more information is saved as hs_err_pid2704.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#

The pstack tool shows that the crash is due to an unexpected SIGSEGV in PSMarkSweep::invoke_no_policy(), which is the function that starts a Full GC when UseParallelOldGC is enabled. So it looks as though the crash is actually happening during the Full GC that's forced prior to the actual dumping of the heap:

 ff3692f0 __sigprocmask (ff36b8f4, 0, 0, fa981d98, ff37c000, 0) + 8
 ff35dd34 _sigon   (fa981d98, ff3838b0, 6, fa980edc, fa981d98, ff383224) + d0
 ff360d90 _thrp_kill (0, 6, 6, ff37c000, 6, ff2c0458) + f8
 ff24bdd8 raise    (6, 0, 0, ffffffff, ff2c03c4, 6000) + 40
 ff235984 abort    (ff2bc008, 33928, 0, fe595324, fe56c000, fe5985d0) + 100
 fe43d098 __1cCosFabort6Fi_v_ (1, 5360, 12efb8, 1aa, fe56c000, 5000) + 58
 fe4d1678 __1cHVMErrorOreport_and_die6M_v_ (0, fe58b2f0, 4400, fe441550, fe4d7e6e, fe441550) + c8c
 fe21319c JVM_handle_solaris_signal (b, fa981630, fa981378, 5800, 11, 1447b8) + a40
 ff36b218 __sighndlr (b, fa981630, fa981378, fe21273c, fa981e40, fa981e30) + c
 ff36821c sigacthandler (b, fa981d98, 0, 0, 0, ff37c000) + 708
 --- called from signal handler with signal 11 (SIGSEGV) ---
 fe4583a4 __1cLPSMarkSweepQinvoke_no_policy6Fpii_v_ (0, fe5879e4, 1, f85818d8, 6564, 7) + 20c
 fe458150 __1cLPSMarkSweepGinvoke6Fpii_v_ (f85818d8, 1, fe57fd1c, 1, 0, f85818d8) + a4
 fe4d3878 __1cNVM_HeapWalkerEdoit6M_v_ (f85818bc, fe449df0, 1447b8, fe0d8ccc, fa9, 7d4c0e) + e8
 fe1c202c __1cMVM_OperationIevaluate6M_v_ (f85818bc, adf00, 144c54, 144860, 144868, 7d4c0e) + 80
 fe0d6fac __1cIVMThreadDrun6M_v_ (fe58614c, adf00, 144860, 55f8, 144868, f85818bc) + 6d0
 fe43cd38 __1cG_start6Fpv_0_ (1447b8, fe586a34, fe57f8dc, 0, 3418, fe56c000) + 200
 ff36b11c _thread_start (1447b8, 0, 0, 0, 0, 0) + 40

The crash also occurs on Windows, where you get this error:

On Windows you will see this error if you try to gather a heapdump by pressing CTRL-BREAK:

#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6d7a01ca, pid=3004, tid=4528
#
# Java VM: Java HotSpot(TM) Client VM (1.5.0_16-b02 mixed mode)
# Problematic frame:
# V  [jvm.dll+0x601ca]
#
# An error report file with more information is saved as hs_err_pid3004.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#
Comments
EVALUATION The fix for 6441368 is in 1.5.0 update release. Looks like the fix is to modify VM_HeapWalker::doit() function to call ParallelScavengeHeap::invoke_full_gc() instead of PSMarkSweep::invoke() like what John suggests.
02-10-2008
EVALUATION The fix for 6441368 would be useful here--it adds a method ParallelScavengeHeap::invoke_full_gc() that can be called to invoke a full gc. The method tests whether UseParallelOldGC is enabled and does the right thing.
02-10-2008
EVALUATION This may indeed be problems here as the built-in heap dumper that is in jdk5 (since update 7) came from jdk6 and may pre-date the parallel old space collector. It is possible that the heap dumper has never been tested with this collector (in jdk5).
02-10-2008
WORK AROUND Do not use the -XX:+UseParallelOldGC option.
01-10-2008