JDK-8011596 : GC crashes during JPRT testing on OSX
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: hs25
  • Priority: P3
  • Status: Resolved
  • Resolution: Cannot Reproduce
  • OS: os_x
  • CPU: x86
  • Submitted: 2013-04-05
  • Updated: 2013-09-12
  • Resolved: 2013-05-21
Related Reports
Relates :  
Description
I've now seen a couple of JPRT test jobs that have crashed on OSX when doing GC:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x000000010d8b0685, pid=31483, tid=14595
#
# JRE version: Java(TM) SE Runtime Environment (8.0-b83) (build 1.8.0-ea-b83)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.0-b26-internal-201304042344.daholme.hotspot-rt mixed mode bsd-amd64 compressed oops)
# Problematic frame:
# V  [libjvm.dylib+0x1b3685]
#
# Core dump written. Default location: /cores/core or core.31483
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.sun.com/bugreport/crash.jsp
#

---------------  T H R E A D  ---------------

Current thread (0x00007fe7b8815800):  GCTaskThread [stack: 0x00000001304c8000,0x00000001305c8000] [id=14595]


#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/opt/jprt/T/P1/131255.hseigel/s/src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.hpp:433), pid=72049, tid=15619
#  assert(addr <= region_start() + region_size()) failed: addr too big
#
# JRE version: Java(TM) SE Runtime Environment (8.0-b82) (build 1.8.0-ea-b82)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.0-b25-internal-201303251312.hseigel.bug_7154889-nojdk-fastdebug mixed mode bsd-amd64 compressed oops)
# Core dump written. Default location: /cores/core or core.72049
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.sun.com/bugreport/crash.jsp
#

---------------  T H R E A D  ---------------

Current thread (0x00007fcfb3028800):  GCTaskThread [stack: 0x000000011e416000,0x000000011e516000] [id=15619]

Stack: [0x000000011e416000,0x000000011e516000],  sp=0x000000011e5152f0,  free space=1020k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.dylib+0x7b2c76]  VMError::report_and_die()+0x622
V  [libjvm.dylib+0x2d320d]  report_vm_error(char const*, int, char const*, char const*)+0x63
V  [libjvm.dylib+0x63b4be]  ParMarkBitMap::mark_obj(HeapWord*, unsigned long)+0x1ce
V  [libjvm.dylib+0x3e76a9]  void PSParallelCompact::mark_and_push<unsigned int>(ParCompactionManager*, unsigned int*)+0x14b
V  [libjvm.dylib+0x3de888]  InstanceKlass::oop_follow_contents(ParCompactionManager*, oopDesc*)+0x1d8
V  [libjvm.dylib+0x659ac5]  oopDesc::follow_contents(ParCompactionManager*)+0x18d
V  [libjvm.dylib+0x66c493]  ParCompactionManager::follow_marking_stacks()+0x7f
V  [libjvm.dylib+0x659077]  StealMarkingTask::do_it(GCTaskManager*, unsigned int)+0xe7
V  [libjvm.dylib+0x3825e0]  GCTaskThread::run()+0x1fe
V  [libjvm.dylib+0x62a228]  java_start(Thread*)+0xe4
C  [libsystem_c.dylib+0x14742]  _pthread_start+0x147
C  [libsystem_c.dylib+0x1181]  thread_start+0xd

and there may be others scattered through the JPRT archives.

I can't tell if these are actually related of course.
Comments
I have been running GCBasher a lot on OSX without reproducing this bug. The fix for JDK-8014339 introduce extra information to the failing assert. To make sure that new failures are not hidden by this bug I am closing this bug for now. If/when it happens again we should reopen and hopefully we have some more information from the new assert message.
21-05-2013

As the bug has re-appeared I've re-opened the report.
10-05-2013

It might be possible that this is being caused by the linkage problems we have discovered on OSX - JDK-8014326
10-05-2013

Closed as CNR.
16-04-2013

I have not been able to reproduce this with GCBasher.
12-04-2013