JDK-6987400 : G1: assert(!is_null(v)) failed: narrow oop value can never be zero, oop.inline.hpp:172
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 7
  • Priority: P4
  • Status: Closed
  • Resolution: Cannot Reproduce
  • OS: linux
  • CPU: x86
  • Submitted: 2010-09-25
  • Updated: 2013-09-18
  • Resolved: 2011-01-25
Related Reports
Relates :  
JDK-6994850 - G1: nsk/monitoring/stress/classload/* crash with JDK b114 and G1 enabled
Relates :  
JDK-6977804 - G1: remove the zero-filling thread
Relates :  
JDK-6982509 - Assertion failure triggered by jnistress005
Description
The nightly test:

gc/gctests/FinalizeTest01

fails with the following assert:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/tmp/jprt/P1/B/191456.jcoomes/source/src/share/vm/oops/oop.inline.hpp:172), pid=2103, tid=140348203940176
#  assert(!is_null(v)) failed: narrow oop value can never be zero
#
# JRE version: 7.0
# Java VM: OpenJDK 64-Bit Server VM (20.0-b01-201009151914.jcoomes.jprt-jdk7tools-fastdebug mixed mode linux-amd64 compressed oops)
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#

The link to the failing test is at:

http://sqeweb.sfbay.sun.com/nfs/tools/gtee/results/JDK7/NIGHTLY/VM/2010-09-15/G1_GC_Baseline/vm/linux-amd64/server/mixed/linux-amd64_vm_server_mixed_vm.gc.testlist/analysis.html

http://sqeweb.sfbay.sun.com/nfs/tools/gtee/results/JDK7/NIGHTLY/VM/2010-09-15/G1_GC_Baseline/vm/linux-amd64/server/mixed/linux-amd64_vm_server_mixed_vm.gc.testlist/ResultDir/FinalizeTest01/

Stack trace:

Stack: [0x00007fa55cc73000,0x00007fa55cd74000],  sp=0x00007fa55cd71eb0,  free space=1019k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0xa7709c];;  _ZN7VMError6reportEP12outputStream+0x116c
V  [libjvm.so+0xa7746c];;  _ZN7VMError14report_and_dieEv+0x2dc
V  [libjvm.so+0x495b54];;  _Z15report_vm_errorPKciS0_S0_+0x84
V  [libjvm.so+0x435a07];;  _ZN9MarkSweep11mark_objectEP7oopDesc+0x217
V  [libjvm.so+0x86e3e3];;  _ZN13objArrayKlass19oop_follow_contentsEP7oopDesc+0xf3
V  [libjvm.so+0x7dead6];;  _ZN9MarkSweep12follow_stackEv+0x36
V  [libjvm.so+0x87eb96];;  _ZN17InterpreterOopMap11iterate_oopEP13OffsetClosure+0xa6
V  [libjvm.so+0x520091];;  _ZN5frame19oops_interpreted_doEP10OopClosurePK11RegisterMapb+0x251
V  [libjvm.so+0xa18f8e];;  _ZN10JavaThread7oops_doEP10OopClosureP15CodeBlobClosure+0x18e
V  [libjvm.so+0xa1923a];;  _ZN7Threads25possibly_parallel_oops_doEP10OopClosureP15CodeBlobClosure+0x5a
V  [libjvm.so+0x95d6bd];;  _ZN10SharedHeap20process_strong_rootsEbbNS_14ScanningOptionEP10OopClosureP15CodeBlobClosureP16OopsInGenClosure+0x8d
V  [libjvm.so+0x5539fd];;  _ZN11G1MarkSweep17mark_sweep_phase1ERbb+0xad
V  [libjvm.so+0x5542e1];;  _ZN11G1MarkSweep19invoke_at_safepointEP18ReferenceProcessorb+0x101
V  [libjvm.so+0x53ad51];;  _ZN15G1CollectedHeap13do_collectionEbbm+0x5e1
V  [libjvm.so+0x53c72f];;  _ZN15G1CollectedHeap25satisfy_failed_allocationEm+0x8f
V  [libjvm.so+0xa9660c];;  _ZN25VM_G1CollectForAllocation4doitEv+0x4c
V  [libjvm.so+0xa955bf];;  _ZN12VM_Operation8evaluateEv+0x8f
V  [libjvm.so+0xa93690];;  _ZN8VMThread18evaluate_operationEP12VM_Operation+0xc0
V  [libjvm.so+0xa94385];;  _ZN8VMThread4loopEv+0x525
V  [libjvm.so+0xa945a5];;  _ZN8VMThread3runEv+0xb5
V  [libjvm.so+0x8901a0];;  _ZL10java_startP6Thread+0xf0

JavaThread 0x000000000062c000 (nid = 2104) was being processed
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  nsk.share.gc.gp.array.ByteArrayProducer.create(J)[B+5
j  nsk.share.gc.gp.array.ByteArrayProducer.create(J)Ljava/lang/Object;+2
j  nsk.share.gc.gp.GarbageUtils.eatMemory(Lnsk/share/test/ExecutionController;Lnsk/share/gc/gp/GarbageProducer;JJJ)V+56
j  nsk.share.gc.gp.GarbageUtils.eatMemory(Lnsk/share/test/ExecutionController;JJJ)V+10
j  nsk.share.gc.Algorithms.eatMemory(Lnsk/share/test/ExecutionController;)V+10
j  gc.gctests.FinalizeTest01.FinalizeTest01.runOne()V+80
j  gc.gctests.FinalizeTest01.FinalizeTest01.run()V+89

The version of the VM is:

Java VM: OpenJDK 64-Bit Server VM (20.0-b01-201009151914.jcoomes.jprt-jdk7tools-fastdebug mixed mode linux-amd64 compressed oops)

bit has also failed with:

Java VM: OpenJDK 64-Bit Server VM (20.0-b01-201009202142.jmasa.hg_gc_baseline_JTergo-fastdebug mixed mode linux-amd64 compressed oops)

The rerun script (which runs the test in a loop) is attached.

The machine the test failed on is "Machine: vm-v20z-23"
Comments
EVALUATION Instrumentation confirms that the race between the zero thread and object allocation/initialization. We are marking the root objects and come across a humongous array (reachable from the Java frame) whose klass is null.
25-01-2011
PUBLIC COMMENTS This issue seems to be very intermittent. It failed after ~2240 iterations: ==== Run 2239 / Fail 0 ==== Warning: Cannot open log file: hotspot.log Warning: Forcing option -XX:LogFile=/tmp/hs_pid30913.log Stress time: 60 Stress iterations factor: 1 Stress threads factor: 1 Max memory: 1004535808 Sleep time: 500 Iterations: 0 Number of threads: 4 Seed: 1285333443043 Run GC thread: false Run mem diag thread: false Run forever: false Allocating 294297 objects. 1 out of 5 will have a finalizer. # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/oop.inline.hpp:172 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/tmp/jprt/P1/B/214221.jmasa/source/src/share/vm/oops/oop.inline.hpp:172), pid=30913, tid=140045262887248 # assert(!is_null(v)) failed: narrow oop value can never be zero # # JRE version: 7.0 # Java VM: OpenJDK 64-Bit Server VM (20.0-b01-201009202142.jmasa.hg_gc_baseline_JTergo-fastdebug mixed mode linux-amd64 compressed oops) # An error report file with more information is saved as: # /tmp/hs_err_pid30913.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # Current thread is 140045262887248 Dumping core ... /home/jc234399/rerun.sh.FinalizeTest01: line 83: 30913: Abort Status: 262 I am submitting this bug to track this. It might be worth noting that the test is run with +ExplicitGCInvokesConcurrent. In G1 this flag causing calls to System.gc() to be converted from Full GCs to incremental evacuation pauses that initiate a marking cycle. The thread making the System.gc() call blocks/waits until the makring cycle completes. The fact that we have a null object when we're not supposed to could indicate a marking issue (we might have incorrectly freed and cleared a heap region).
25-09-2010