JDK-6478685 : Crash in java.util.HashMap$KeySet.(Ljava/util/HashMap;)
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 6
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: solaris_8
  • CPU: sparc
  • Submitted: 2006-10-05
  • Updated: 2015-04-17
  • Resolved: 2008-07-08
Related Reports
Duplicate :  
Duplicate :  
Description
3 JVM crashes happened on test nsk/monitoring/stress/lowmem/lowmem030 on Solaris-SPARC 64-bit:

##
##  SIGSEGV (0xb) at pc=0xffffffff77c1c1fc, pid=11569, tid=18
##
## Java VM: Java HotSpot(TM) 64-Bit Server VM (1.6.0-rc-b100 mixed mode)
## Problematic frame:
## j  java.util.HashMap$KeySet.<init>(Ljava/util/HashMap;)V+2
##
## An error report file with more information is saved as hs_err_pid11569.log
##

The stack was:

Stack: [0xffffffff60502000,0xffffffff60601c50),  sp=0xffffffff60600740,  free space=1017k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
j  java.util.HashMap$KeySet.<init>(Ljava/util/HashMap;)V+2
j  java.util.HashMap$KeySet.<init>(Ljava/util/HashMap;Ljava/util/HashMap$1;)V+2
j  java.util.HashMap.keySet()Ljava/util/Set;+20
j  java.util.HashSet.iterator()Ljava/util/Iterator;+4
j  nsk.share.monitoring.MemoryMonitor.getMemoryPoolMXBeansOnServer()[Ljavax/management/ObjectName;+20
j  nsk.share.monitoring.MemoryMonitor.updateCollectionThresholds()V+447
j  nsk.share.monitoring.MemoryMonitor.access$1000(Lnsk/share/monitoring/MemoryMonitor;)V+1
j  nsk.share.monitoring.MemoryMonitor$Polling.pollCollectionThresholds()V+924
j  nsk.share.monitoring.MemoryMonitor$Polling.run()V+14
v  ~StubRoutines::call_stub
V  [libjvm.so+0x15c568]
V  [libjvm.so+0x41f71c]
V  [libjvm.so+0x207d04]
V  [libjvm.so+0x21b280]
V  [libjvm.so+0x6a5624]
V  [libjvm.so+0x60f48c]

Two more crashes at the same PC occured when trying to re-run the test:

#  SIGSEGV (0xb) at pc=0xffffffff77c1c1fc, pid=25963, tid=18
#
# Java VM: Java HotSpot(TM) 64-Bit Server VM (1.6.0-rc-b100 mixed mode)
# Problematic frame:
# j  java.util.Hashtable$Enumerator.hasMoreElements()Z+35
#

#  SIGSEGV (0xb) at pc=0xffffffff77c1c1fc, pid=26017, tid=18
#
# Java VM: Java HotSpot(TM) 64-Bit Server VM (1.6.0-rc-b100 mixed mode)
# Problematic frame:
# j  java.util.HashMap.transfer([Ljava/util/HashMap$Entry;)V+58

Comments
EVALUATION The failure occurs when the card table is expanded to cover a newly expanded part of the heap. Writing to the newly expanded part of the card table crashes the VM as if the card table has not been expanded. The reason for the crash at that point is still unknown.
10-07-2007

WORK AROUND The failure occurs only when the heap is grown. Setting the heap minimum and maximum value to the same number will workaround this bug.
10-07-2007

EVALUATION Using any other collecter does not exhibit this failure, I am reassigning this bug to the GC team for further evaluation. Please see comments section on how to reproduce the bug.
16-10-2006