JDK-8030065 : SEGV in BitMap::get_next_one_offset_inline_aligned_right()
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 6u65,6u71
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_10
  • CPU: sparc
  • Submitted: 2013-12-12
  • Updated: 2015-05-28
  • Resolved: 2015-03-12
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.
JDK 6
6u101 b03Fixed
Related Reports
Relates :  
JDK-8006066 - fix for JDK-6294277 causes GC crash regression
Relates :  
JDK-6294277 - java -Xdebug crashes on SourceDebugExtension attribute larger than 64K
Description
64-bit Java SE 6u65 processes receive signal SEGV intermittently:


Error message:

# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0xffffffff7e083510, pid=15647, tid=26
#
# JRE version: 6.0_65-b14
# Java VM: Java HotSpot(TM) 64-Bit Server VM (20.65-b04 mixed mode solaris-sparc compress
ed oops)
# Problematic frame:
# V  [libjvm.so+0x883510]  unsigned long BitMap::get_next_one_offset_inline_aligned_right(unsigned long,unsigned long)const+0x20

Pattern is consistent:

% grep '# V' *
hs_err_pid15647.log:# V  [libjvm.so+0x883510]  unsigned long BitMap::get_next_one_offset_inline_aligned_right(unsigned long,unsigned long)const+0x20
hs_err_pid2251.log:# V  [libjvm.so+0x883510]  unsigned long BitMap::get_next_one_offset_inline_aligned_right(unsigned long,unsigned long)const+0x20
hs_err_pid3014.log:# V  [libjvm.so+0x883510]  unsigned long BitMap::get_next_one_offset_inline_aligned_right(unsigned long,unsigned long)const+0x20
hs_err_pid7942.log:# V  [libjvm.so+0x883510]  unsigned long BitMap::get_next_one_offset_inline_aligned_right(unsigned long,unsigned long)const+0x20
%

% grep '^#  SIGSEGV' *
hs_err_pid15647.log:#  SIGSEGV (0xb) at pc=0xffffffff7e083510, pid=15647, tid=26
hs_err_pid2251.log:#  SIGSEGV (0xb) at pc=0xffffffff7e083510, pid=2251, tid=6
hs_err_pid3014.log:#  SIGSEGV (0xb) at pc=0xffffffff7e083510, pid=3014, tid=6
hs_err_pid7942.log:#  SIGSEGV (0xb) at pc=0xffffffff7e083510, pid=7942, tid=26
%

% grep elapsed *
hs_err_pid15647.log:elapsed time: 2155 seconds
hs_err_pid2251.log:elapsed time: 46778 seconds
hs_err_pid3014.log:elapsed time: 75547 seconds
hs_err_pid7942.log:elapsed time: 90029 seconds
%

Stack trace of failing thread:

hs_err_pid15647.log
Stack: [0xffffffff73000000,0xffffffff73100000],  sp=0xffffffff730ff030,  free space=1020k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x883510]  unsigned long BitMap::get_next_one_offset_inline_aligned_right(unsigned long,unsigned long)const+0x20
V  [libjvm.so+0x8adefc]  HeapWord*ParallelCompactData::calc_new_pointer(HeapWord*)+0x88
V  [libjvm.so+0x5e06f8]  int instanceKlassKlass::oop_update_pointers(ParCompactionManager*,oopDesc*)+0x80
V  [libjvm.so+0x8b50a4]  ParMarkBitMap::IterationStatus MoveAndUpdateClosure::do_addr(HeapWord*,unsigned long)+0x74
V  [libjvm.so+0x88323c]  ParMarkBitMap::IterationStatus ParMarkBitMap::iterate(ParMarkBitMapClosure*,unsigned long,unsigned long)const+0x9c
V  [libjvm.so+0x8b4ddc]  void PSParallelCompact::move_and_update(ParCompactionManager*,PSParallelCompact::SpaceId)+0x174
V  [libjvm.so+0x8b1f98]  void PSParallelCompact::compact_perm(ParCompactionManager*)+0x78
V  [libjvm.so+0x8b0d0c]  void PSParallelCompact::invoke_no_policy(bool)+0x5f4
V  [libjvm.so+0x8b8388]  void PSScavenge::invoke()+0x198
V  [libjvm.so+0x88a110]  HeapWord*ParallelScavengeHeap::failed_mem_allocate(unsigned long,bool)+0xc0
V  [libjvm.so+0x263784]  void VM_ParallelGCFailedAllocation::doit()+0xac
V  [libjvm.so+0x25fc24]  void VM_Operation::evaluate()+0x8c
V  [libjvm.so+0x9c169c]  void VMThread::evaluate_operation(VM_Operation*)+0xd4
V  [libjvm.so+0x9c1bb4]  void VMThread::loop()+0x40c
V  [libjvm.so+0x2d6cf4]  void VMThread::run()+0xa4
V  [libjvm.so+0x86fde4]  java_start+0x164


The failure pattern is pretty consistent.
The only difference was:

VM_Operation (0xfffffffdaaafea70): ParallelGCFailedAllocation, mode: safepoint, requested by thread 0x0000000108fa9000

vs.
VM_Operation (0xfffffffda4dfca38): ParallelGCSystemGC, mode: safepoint, requested by thread 0x0000000104303000


In all cases, the following runtime parameter was configured:
-Xrunjdwp:transport=dt_socket,server=y,address=25008,suspend=n

So,  /opt/jdk1.6.0_65/jre/lib/sparcv9/libjdwp.so was used.
Comments
Ran test case on 7, did not reproduce
28-05-2015
Regression from JDK-6294277 not completely fixed.
27-02-2015
Regression from JDK-6294277 not completely fixed.
27-02-2015
Now understand the problem. Formulating the solution.
27-02-2015
Moving from hotspot/runtime -> hotspot/jvmti since there are indications that libjdwp.so is involved here. If this turns out to be a problem in the JVM, then hotspot/jvmti is still a good home. If this turns out to be a problem in libjdwp.so, then this bug will need to move to core-svc/debugger.
12-12-2013
Workaround: The instability was no longer observed after the -Xrunjdwp parameter was removed from the Java runtime parameters. This was consistent with the observation: other processes running the same application on identical Java SE software without ever having used the -Xrunjdwp parameter have never encountered such instabilities.
12-12-2013