JDK-8296915 : assert(Universe::is_in_heap(result)) failed: object not in heap 0x0000000000000010
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 20
  • Priority: P3
  • Status: Closed
  • Resolution: Cannot Reproduce
  • OS: os_x
  • CPU: x86_64
  • Submitted: 2022-11-13
  • Updated: 2023-01-09
  • Resolved: 2023-01-09
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 21
21Resolved
Related Reports
Relates :  
JDK-8299274 - Add elements to resolved_references consistently
Relates :  
JDK-8291830 - jvmti/RedefineClasses/StressRedefine failed: assert(!is_null(v)) failed: narrow klass value can never be zero
Relates :  
JDK-8299275 - Add some ClassLoaderData verification code
Description
Test: runtime/SelectionResolution/InvokeInterfaceSuccessTest.java

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/System/Volumes/Data/mesos/work_dir/slaves/0c72054a-24ab-4dbb-944f-97f9341a1b96-S131499/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/35653521-a0c6-4c07-8b64-6982330ad9ee/runs/05b29f7f-19ed-4148-86af-88c02d7139cf/workspace/open/src/hotspot/share/oops/compressedOops.inline.hpp:58), pid=81209, tid=25091
#  assert(Universe::is_in_heap(result)) failed: object not in heap 0x0000000000000010
#
# JRE version: Java(TM) SE Runtime Environment (20.0+24) (fastdebug build 20-ea+24-1720)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 20-ea+24-1720, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, bsd-amd64)
# Core dump will be written. Default location: core.81209
#

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

Current thread (0x00007fb3c7787f50):  WorkerThread "GC Thread#2" [stack: 0x0000700010689000,0x0000700010789000] [id=25091]

Stack: [0x0000700010689000,0x0000700010789000],  sp=0x00007000107885b0,  free space=1021k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.dylib+0x12c2019]  VMError::report_and_die(int, char const*, char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x6d9  (compressedOops.inline.hpp:58)
V  [libjvm.dylib+0x12c268b]  VMError::report_and_die(Thread*, void*, char const*, int, char const*, char const*, __va_list_tag*)+0x3b
V  [libjvm.dylib+0x6cdb3d]  report_vm_error(char const*, int, char const*, char const*, ...)+0xdd
V  [libjvm.dylib+0x30dd4a]  CompressedOops::decode_not_null(narrowOop)+0x13a
V  [libjvm.dylib+0x89beaa]  void G1ScanEvacuatedObjClosure::do_oop_work<narrowOop>(narrowOop*)+0x2a
V  [libjvm.dylib+0x897cbb]  void objArrayOopDesc::oop_iterate_range<G1ScanEvacuatedObjClosure>(G1ScanEvacuatedObjClosure*, int, int)+0x26b
V  [libjvm.dylib+0x8979fc]  G1ParScanThreadState::do_partial_array(PartialArrayScanTask)+0x75c
V  [libjvm.dylib+0x898638]  G1ParScanThreadState::dispatch_task(ScannerTask)+0x108
V  [libjvm.dylib+0x898db3]  G1ParScanThreadState::trim_queue_to_threshold(unsigned int)+0x1e3
V  [libjvm.dylib+0x89493d]  G1ParScanThreadState::trim_queue_partially()+0x5d
V  [libjvm.dylib+0x8c83f5]  void G1ParCopyClosure<(G1Barrier)1, false>::do_oop_work<oop>(oop*)+0x435
V  [libjvm.dylib+0x5ec11a]  ClassLoaderData::oops_do(OopClosure*, int, bool)+0x8a
V  [libjvm.dylib+0x8948a3]  G1CLDScanClosure::do_cld(ClassLoaderData*)+0x33
V  [libjvm.dylib+0x5f1752]  ClassLoaderDataGraph::roots_cld_do(CLDClosure*, CLDClosure*)+0x52
V  [libjvm.dylib+0x8cb1b4]  G1RootProcessor::process_java_roots(G1RootClosures*, G1GCPhaseTimes*, unsigned int)+0xc4
V  [libjvm.dylib+0x8cb03e]  G1RootProcessor::evacuate_roots(G1ParScanThreadState*, unsigned int)+0x5e
V  [libjvm.dylib+0x8dc14f]  G1EvacuateRegionsTask::scan_roots(G1ParScanThreadState*, unsigned int)+0x1f
V  [libjvm.dylib+0x8dbfe3]  G1EvacuateRegionsBaseTask::work(unsigned int)+0x93
V  [libjvm.dylib+0x131f3ac]  WorkerThread::run()+0x7c
V  [libjvm.dylib+0x12104e7]  Thread::call_run()+0x177
V  [libjvm.dylib+0xf7032f]  thread_native_entry(Thread*)+0x14f
C  [libsystem_pthread.dylib+0x6109]  _pthread_start+0x94
C  [libsystem_pthread.dylib+0x1b8b]  thread_start+0xf

G1 has found a bad oop, but where did it come from?
Comments
This happened once and I cannot find what could have been the cause. I added verification code and other code to make resolved_references array elements never have an oop value of 0x10. Closing as CNR.
09-01-2023
Deep in the access code, there are assertions. V [libjvm.so+0xa6ca4c] AccessInternal::PostRuntimeDispatch<G1BarrierSet::AccessBarrier<1335398ul, G1BarrierSet>, (AccessInternal::BarrierType)1, 1335398ul>::oop_access_barrier(oop, long, oop)+0x84c (compressedOops.inline.hpp:69) V [libjvm.so+0xa6b4b8] AccessInternal::RuntimeDispatch<1335366ul, oop, (AccessInternal::BarrierType)1>::store_at_init(oop, long, oop)+0xa8 (access.inline.hpp:288) V [libjvm.so+0xa6e469] objArrayOopDesc::obj_at_put(int, oop)+0x149 (accessBackend.hpp:472) OR, passing InstanceKlass* ik as an oop (without CompressedOops): # assert(_whole_heap.contains(p)) failed: Attempt to access p = 0x0000000080045f28 out of bounds of card marking array's _whole_heap = [0x00007f1193000000,0x00007f1993000000) The code I have in review, adds some is_oop_or_null() assertions that are specific to the resolved_references array code.
03-01-2023
It would be good if "::oop_store_at(" checked that it is an oop we are storing in debug builds.
02-01-2023
This only happened once and we're not able to reproduce this. We're going to open a couple of RFEs to verify that oops added to the resolved_references() are oops, and another to verify the resolved_references() with GC verification, and likely close this as CNR.
22-12-2022
Did 10k iterations with 14 fast/4 slow-debug instances running concurrently, all passed. Opened core, I didn't find anything.
15-12-2022
It seem like it could be resolved_references array which contains a bad oop that gives 0x0000000000000010 after widening. There are plenty full places were we insert into this, I have not found anything regarding these.
15-12-2022
This is not the same as JDK-8291830 because Classes redefined (0 events): No events
01-12-2022
ILW = HLM = P3
15-11-2022