JDK-6656830 : assert((*p)->is_oop(),"expected an oop while scanning weak refs")
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: hs12,5.0u22,6u14,7
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2008-01-30
  • Updated: 2012-02-01
  • Resolved: 2011-03-07
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 JDK 7 Other
6u21pFixed 7Fixed hs19Fixed
Related Reports
Relates :  
JDK-6965671 - fatal error: acquiring lock JNIGlobalHandle_lock/16 out of order with lock CodeCache_lock/1
Relates :  
JDK-6578152 - fill_region_with_object has usability and safety issues
Relates :  
JDK-6453355 - new No_Safepoint_Verifier uses fail during GC
Description
Another crash mode is:

#
# An unexpected error has been detected by Java Runtime Environment:
#
#  Internal Error (/ramdisk/PrtBuildDir/workspace/src/share/vm/gc_implementation/shared/markSweep.inline.hpp:38), pid=25298, tid=2912181152
#  Error: assert(Universe::heap()->is_in_reserved(new_pointer),"should be in object space")
#
# Java VM: Java HotSpot(TM) Client VM (12.0-b01-20080125125234.ss45998.hs_spv-fastdebug compiled mode linux-x86)
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#

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

Current thread (0x080ba000):  VMThread [stack: 0xad8c5000,0xad946000] [id=25302]

Stack: [0xad8c5000,0xad946000],  sp=0xad944c00,  free space=511k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x775c0b];;  VMError::report_and_die()+0x26b
V  [libjvm.so+0x3afd35];;  report_assertion_failure(char const*, int, char const*)+0x55
V  [libjvm.so+0x1d5912];;  MarkSweep::_adjust_pointer(oopDesc**, bool)+0x92
V  [libjvm.so+0x4c943a];;  JNIHandleBlock::weak_oops_do(BoolObjectClosure*, OopClosure*)+0x11a
V  [libjvm.so+0x4c8a89];;  JNIHandles::weak_oops_do(BoolObjectClosure*, OopClosure*)+0x19
V  [libjvm.so+0x6a9ec5];;  SharedHeap::process_weak_roots(OopClosure*, OopClosure*)+0x15
V  [libjvm.so+0x3eccfc];;  GenCollectedHeap::gen_process_weak_roots(OopClosure*, OopClosure*)+0x1c
V  [libjvm.so+0x3ef972];;  GenMarkSweep::invoke_at_safepoint(int, ReferenceProcessor*, bool)+0x332
V  [libjvm.so+0x3fcfe1];;  OneContigSpaceCardGeneration::collect(bool, bool, unsigned int, bool)+0x71
V  [libjvm.so+0x3ec574];;  GenCollectedHeap::do_collection(bool, bool, unsigned int, bool, int)+0x954
V  [libjvm.so+0x3571c5];;  GenCollectorPolicy::satisfy_failed_allocation(unsigned int, bool)+0xc5
V  [libjvm.so+0x3ecb1c];;  GenCollectedHeap::satisfy_failed_allocation(unsigned int, bool)+0x1c
V  [libjvm.so+0x776b82];;  VM_GenCollectForAllocation::doit()+0x72
V  [libjvm.so+0x7b07b6];;  VM_Operation::evaluate()+0x76
V  [libjvm.so+0x7af8dd];;  VMThread::evaluate_operation(VM_Operation*)+0x9d
V  [libjvm.so+0x7afbbd];;  VMThread::loop()+0x12d
V  [libjvm.so+0x7af5b5];;  VMThread::run()+0xb5
V  [libjvm.so+0x6484a8];;  java_start(Thread*)+0x138
C  [libpthread.so.0+0x52ab]

VM_Operation (0xb7e45ccc): GenCollectForAllocation, mode: safepoint, requested by thread 0x08063c00


---------------  P R O C E S S  ---------------

Java Threads: ( => current thread )
  0x0815cc00 JavaThread "JVMTI agent thread" daemon [_thread_in_native, id=25358, stack(0xad5d1000,0xad622000)]
  0x080e2800 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=25307, stack(0xad700000,0xad751000)]
  0x080dec00 JavaThread "CompilerThread0" daemon [_thread_blocked, id=25306, stack(0xad751000,0xad7d2000)]
  0x080dd000 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=25305, stack(0xad7d2000,0xad823000)]
  0x080c0800 JavaThread "Finalizer" daemon [_thread_blocked, id=25304, stack(0xad823000,0xad874000)]
  0x080bf000 JavaThread "Reference Handler" daemon [_thread_blocked, id=25303, stack(0xad874000,0xad8c5000)]
  0x08063c00 JavaThread "main" [_thread_blocked, id=25301, stack(0xb7df6000,0xb7e47000)]

Other Threads:
=>0x080ba000 VMThread [stack: 0xad8c5000,0xad946000] [id=25302]
  0x080e5000 WatcherThread [stack: 0xad67f000,0xad700000] [id=25308]

VM state:at safepoint (normal execution)
This is from the Dan's service_hs nightly analysis 2008.01.26 (final):
  URL: http://sqeweb.sfbay/nfs/results/vm/gtee/JDK7/NIGHTLY/VM/2008-01-26/Serv_Baseline/

  nsk/jvmti/scenarios/events/EM02/em02t003
        This test failed the following assertion:
            Internal Error (src/share/vm/memory/defNewGeneration.cpp:84)
            Error: assert((*p)->is_oop(),"expected an oop while scanning weak refs")

        on Linux IA32 Client VM (machine pacmanjr). This test is
        covered by two different bugs in state "fix available":
            6453355 4/4 new No_Safepoint_Verifier uses fail during GC
            6620630 3/4 G1: guarantee(variance() > -1.0,"variance
                        should be >= 0") at numberSeq.cpp:180

        The synopsis for 6620630 includes the "G1:" prefix so I think
        that bug is related to the new G1 collector which this nightly
        does not exercise. So I don't think 6620630 is related.

        6453355 is the most recent fix that we're testing in nightly so
        this failure may be an existing problem exposed by that fix or
        it may be a new regression introduced by that fix.

   nsk/jvmti/scenarios/events/EM07/em07t002
        This test failed the following assertion:
            Internal Error (src/share/vm/memory/defNewGeneration.cpp:84)
            Error: assert((*p)->is_oop(),"expected an oop while scanning weak refs")

        on Win32 Client VM (machine colfax005). 

This is the hs_err_pid28725.log file of the em02t003 test crash on Linux IA32 Client VM (machine pacmanjr):
#
# An unexpected error has been detected by Java Runtime Environment:
#
#  Internal Error (/ramdisk/PrtBuildDir/workspace/src/share/vm/memory/defNewGeneration.cpp:84), pid=28725, tid=2913295264
#  Error: assert((*p)->is_oop(),"expected an oop while scanning weak refs")
#
# Java VM: Java HotSpot(TM) Client VM (12.0-b01-20080125125234.ss45998.hs_spv-fastdebug compiled mode linux-x86)
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#

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

Current thread (0x080af800):  VMThread [stack: 0xad9d5000,0xada56000] [id=28730]

Stack: [0xad9d5000,0xada56000],  sp=0xada54a00,  free space=510k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x775c0b];;  VMError::report_and_die()+0x26b
V  [libjvm.so+0x3afd35];;  report_assertion_failure(char const*, int, char const*)+0x55
V  [libjvm.so+0x3b6032];;  DefNewGeneration::FastKeepAliveClosure::do_oop(oopDesc**)+0x192
V  [libjvm.so+0x4c943a];;  JNIHandleBlock::weak_oops_do(BoolObjectClosure*, OopClosure*)+0x11a
V  [libjvm.so+0x4c8a89];;  JNIHandles::weak_oops_do(BoolObjectClosure*, OopClosure*)+0x19
V  [libjvm.so+0x688ccb];;  ReferenceProcessor::process_discovered_references(ReferencePolicy*, BoolObjectClosure*, OopClosure*, VoidClosure*, AbstractRefProcTaskExecutor*)+0x20b
V  [libjvm.so+0x3b7ed3];;  DefNewGeneration::collect(bool, bool, unsigned int, bool)+0x303
V  [libjvm.so+0x3ec574];;  GenCollectedHeap::do_collection(bool, bool, unsigned int, bool, int)+0x954
V  [libjvm.so+0x3571c5];;  GenCollectorPolicy::satisfy_failed_allocation(unsigned int, bool)+0xc5
V  [libjvm.so+0x3ecb1c];;  GenCollectedHeap::satisfy_failed_allocation(unsigned int, bool)+0x1c
V  [libjvm.so+0x776b82];;  VM_GenCollectForAllocation::doit()+0x72
V  [libjvm.so+0x7b07b6];;  VM_Operation::evaluate()+0x76
V  [libjvm.so+0x7af8dd];;  VMThread::evaluate_operation(VM_Operation*)+0x9d
V  [libjvm.so+0x7afbbd];;  VMThread::loop()+0x12d
V  [libjvm.so+0x7af5b5];;  VMThread::run()+0xb5
V  [libjvm.so+0x6484a8];;  java_start(Thread*)+0x138
C  [libpthread.so.0+0x52ab]

VM_Operation (0xb7e4eccc): GenCollectForAllocation, mode: safepoint, requested by thread 0x08063400


---------------  P R O C E S S  ---------------

Java Threads: ( => current thread )
  0x080d4000 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=28735, stack(0xad810000,0xad861000)]
  0x080d0000 JavaThread "CompilerThread0" daemon [_thread_blocked, id=28734, stack(0xad861000,0xad8e2000)]
  0x080ce400 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=28733, stack(0xad8e2000,0xad933000)]
  0x080b6400 JavaThread "Finalizer" daemon [_thread_blocked, id=28732, stack(0xad933000,0xad984000)]
  0x080b4800 JavaThread "Reference Handler" daemon [_thread_blocked, id=28731, stack(0xad984000,0xad9d5000)]
  0x08063400 JavaThread "main" [_thread_blocked, id=28729, stack(0xb7dff000,0xb7e50000)]

Other Threads:
=>0x080af800 VMThread [stack: 0xad9d5000,0xada56000] [id=28730]
  0x080d6800 WatcherThread [stack: 0xad78f000,0xad810000] [id=28736]

VM state:at safepoint (normal execution)

VM Mutex/Monitor currently owned by a thread:  ([mutex/lock_event])
[0x08061d88] UNKNOWN - owner thread: 0x080af800
[0x08062418] UNKNOWN - owner thread: 0x08063400

Heap
 def new generation   total 1856K, used 1026K [0xadcb0000, 0xadeb0000, 0xae190000)
  eden space 1664K,  61% used [0xadcb0000, 0xaddb0868, 0xade50000)
  from space 192K,   0% used [0xade50000, 0xade50000, 0xade80000)
  to   space 192K,   0% used [0xade80000, 0xade80000, 0xadeb0000)
 tenured generation   total 24108K, used 15487K [0xae190000, 0xaf91b000, 0xb1cb0000)
   the space 24108K,  64% used [0xae190000, 0xaf0aff98, 0xaf0b0000, 0xaf91b000)
 compacting perm gen  total 12288K, used 1751K [0xb1cb0000, 0xb28b0000, 0xb5cb0000)
   the space 12288K,  14% used [0xb1cb0000, 0xb1e65c30, 0xb1e65e00, 0xb28b0000)
No shared spaces configured.

...
VM Arguments:
jvm_args: -Xcomp -DHANGINGJAVA18215 -XX:CompileOnly=nsk -Dsun.jvm.hotspot.runtime.VM.disableVersionCheck=1 -agentlib:em02t003=-waittime=5 -XX:-UseGCTimeLimit 
java_command: nsk.jvmti.scenarios.events.EM02.em02t003 /export/local/common/testbase/6/vm/vm/bin/loadclass
Launcher Type: SUN_STANDARD

Environment Variables:
CLASSPATH=/export/local/4234.JDK7.NIGHTLY.VM+linux-i586_client_comp_nsk.jvmti.testlist/results/ResultDir/em02t003:/export/local/common/testbase/6/vm/vm/bin/classes:/export/local/common/jdk/baseline/linux-i586/lib/tools.jar
PATH=/export/local/common/jdk/baseline/linux-i586/bin:/bin:/usr/bin
LD_LIBRARY_PATH=/export/local/common/jdk/baseline/linux-i586/jre/lib/i386/client:/export/local/common/jdk/baseline/linux-i586/jre/lib/i386:/export/local/common/jdk/baseline/linux-i586/jre/../lib/i386:/export/local/common/testbase/6/vm/vm/bin/lib/linux-i586/nsk/jvmti/scenarios/events/EM02:/export/local/common/jdk/baseline/linux-i586/jre/lib/i386:/export/local/common/jdk/baseline/linux-i586/jre/lib/i386/client
SHELL=/bin/ksh
DISPLAY=gtee.sfbay:0

Signal Handlers:
...
---------------  S Y S T E M  ---------------

OS:SUSE Linux Enterprise Server 10 (i586)
VERSION = 10
PATCHLEVEL = 1

uname:Linux 2.6.16.46-0.12-smp #1 SMP Thu May 17 14:00:09 UTC 2007 i686
libc:glibc 2.4 NPTL 2.4 
rlimit: STACK 10000k, CORE 0k, NPROC 16379, NOFILE 1024, AS infinity
load average:0.29 0.23 0.26

CPU:total 2 (1 cores per cpu, 1 threads per core) family 15 model 2 stepping 9, cmov, cx8, fxsr, mmx, sse, sse2

Memory: 4k page, physical 2075076k(717784k free), swap 8393920k(8393792k free)

vm_info: Java HotSpot(TM) Client VM (12.0-b01-20080125125234.ss45998.hs_spv-fastdebug) for linux-x86 JRE (1.7.0), built on Jan 25 2008 16:33:21 by "PRT" with gcc 3.2.1-7 20020903 (release)

time: Sat Jan 26 20:57:39 2008
elapsed time: 0 seconds
I'm testing my fix for 6419370 and I've observed the following
assertion failure:

    Internal Error (src/share/vm/gc_implementation/shared/markSweep.inline.hpp:93)
    Error: assert(Universe::heap()->is_in_reserved(new_obj),"should be in object space")

with the following VM/NSK tests:

    nsk/jvmti/scenarios/events/EM02/em02t003
    nsk/jvmti/scenarios/events/EM07/em07t002

The test config was Solaris X86 Client VM -Xmixed fastdebug VM bits
so I'm removing the 'test-fail-comp' keyword.
I'm testing my fix for 6419370 and I've observed the following
assertion failure:

    Internal Error (src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp:71)
    Error: assert((oopDesc::load_decode_heap_oop_not_null(p))->is_oop(),"expected an oop while scanning weak refs")

with the following VM/NSK tests:

    nsk/jvmti/scenarios/events/EM02/em02t003
    nsk/jvmti/scenarios/events/EM07/em07t002

The test config was Solaris X86 Server VM -Xmixed fastdebug VM bits
so I'm removing the 'test-fail-client' keyword.
Comments
EVALUATION 6656830: assert((*p)->is_oop(),"expected an oop while scanning weak refs") Reviewed-by: dcubed, kvn, twisti This is a long standing bug with the handling of jmethodIDs by the logic for notifying of code unloading. The compiled method unload event passes the jmethodID as part of the event so you need to look it up when an nmethod is unloaded because the class it's associated with is being unloaded. jmethodIDs are loosely coupled to the methodOop so there's an array of them in the instanceKlass and they are searched when the jmethodID for a methodOop is required. jmethodIDs are really just weak JNI references so when their class is being unloaded they all become null so it's impossible to look up the right jmethodID for an nmethod which is being unloaded. In the failing test this results in a new jmethodID being allocated in the middle of the GC which can later lead to crashes since root set has been extended so stale oops are being processed in later phases of the GC. The simplest fix is to cache the jmethodID in the nmethod so that it can be used in the unload notification. I also added logic to complain if new weak references are created while a GC is active.
07-07-2010
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/38e8278318ca
22-06-2010