JDK-8226953 : AOT: assert(oopDesc::is_oop(obj)) failed: not an oop
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 13,14
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • CPU: x86_64
  • Submitted: 2019-06-28
  • Updated: 2019-09-26
  • Resolved: 2019-09-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 14
14 b14Fixed
Related Reports
Duplicate :  
JDK-8229201 - Update Graal
Description
test/hotspot/jtreg/runtime/Thread/StopAtExit.java failed with:

# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc:  SuppressErrorAt=/handles.cpp:36
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (open/src/hotspot/share/runtime/handles.cpp:36), pid=360, tid=442
#  assert(oopDesc::is_oop(obj)) failed: not an oop: 0x000000080072397c
#
# JRE version: Java(TM) SE Runtime Environment (13.0) (fastdebug build 13-ea+0-1392)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 13-ea+0-1392, mixed mode, aot, sharing, tiered, compressed oops, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0xd1aa00]  HandleArea::allocate_handle(oop)+0x160
#
# Core dump will be written. Default location: testoutput/test-support/jtreg_open_test_hotspot_jtreg_hotspot_runtime/scratch/2/core.360
#
# An error report file with more information is saved as:
# testoutput/test-support/jtreg_open_test_hotspot_jtreg_hotspot_runtime/scratch/2/hs_err_pid360.log
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
#
Comments
URL: https://hg.openjdk.java.net/jdk/jdk/rev/d99af76d7689 User: iveresov Date: 2019-09-07 17:05:57 +0000
07-09-2019
Yes, sure we can do that too.
06-09-2019
Igor, how about pushing this directly into JDK? We are not quite ready yet for another Graal merge update.
06-09-2019
It���s been fixed upstream a long time ago. I think [~dlong] is working on the update. I���m not sure on the ETA.
06-09-2019
[~iveresov] This is failing several times a week, is there an ETA on getting the fix integrated?
06-09-2019
This bug was not closed as a duplicate of JDK-8229201. It was closed as "Fixed" and that is why I reopened it. Also, mach5 does not follow duplicate chains. The person analyzing the results would have to see that this bug JDK-8226953 is closed as a duplicate of JDK-8229201 and then link to JDK-8229201 instead of JDK-8226953. Personally, I would not close this bug as a duplicate of JDK-8229201 until JDK-8229201 is integrated and I have verified that this bug is indeed no longer reproducible. However, it is your call on when you wish to close this bug as a duplicate.
28-08-2019
The bug that this one duplicates (JDK-8229201) is open though. I thought it was always the convention that one could close a bug as a duplicate as long as there is at least one open issue tracking the problem. I guess the issue is that mach5 is not displaying the bug status properly because it doesn't walk the duplicate chain?
28-08-2019
This bug should not have been resolved as "Fixed". "Fixed" is only used when there is a changeset that has been pushed to the target repo (jdk/jdk). Once the external fix gets pushed to jdk/jdk, then this bug can be closed as a duplicate of the bug used to push the bits into jdk/jdk. Of course, it would be good to verify that the bug is actually resolved BEFORE closing it as a duplicate.
27-08-2019
The fix is pushed upstream and should be delivered with the next Graal update (JDK-8229201).
09-08-2019
I reproduced it locally my only AOTing java.lang.Thread.interrupted()Z. I guess the problem is in how it deopts.
12-07-2019
Seems like a long-standing problem, history shows failures like that since about December 2018. The "oop" the the assert complains about seems to point into the class space. V [libjvm.dylib+0xc1126d] VMError::report_and_die(int, char const*, char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x6e5 V [libjvm.dylib+0xc11989] VMError::report_and_die(Thread*, void*, char const*, int, char const*, char const*, __va_list_tag*)+0x47 V [libjvm.dylib+0x41afbc] report_vm_error(char const*, int, char const*, char const*, ...)+0x145 V [libjvm.dylib+0x59f182] HandleArea::allocate_handle(oop)+0xd2 V [libjvm.dylib+0x60563f] InterpreterRuntime::resolve_invoke(JavaThread*, Bytecodes::Code)+0x229 V [libjvm.dylib+0x606158] InterpreterRuntime::resolve_from_cache(JavaThread*, Bytecodes::Code)+0xb2 j java.lang.Thread.interrupted()Z+4 java.base@14-internal j java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(I)V+0 java.base@14-internal A 7457 java.util.concurrent.CountDownLatch.await()V java.base@14-internal (9 bytes) @ 0x000000012dd7eda4 [0x000000012dd7ed20+0x0000000000000084] j StopAtExit.run()V+11 v ~StubRoutines::call_stub V [libjvm.dylib+0x60f1f4] JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x3e4 V [libjvm.dylib+0x60dcc5] JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x1f1 V [libjvm.dylib+0x60dde0] JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, Thread*)+0x58 V [libjvm.dylib+0x714b3d] thread_entry(JavaThread*, Thread*)+0x13f V [libjvm.dylib+0xb90075] JavaThread::thread_main_inner()+0x1a1 V [libjvm.dylib+0xb8fc28] JavaThread::run()+0x2aa V [libjvm.dylib+0xb8c6df] Thread::call_run()+0x11b V [libjvm.dylib+0x9f7910] thread_native_entry(Thread*)+0x13a C [libsystem_pthread.dylib+0x3661] _pthread_body+0x154 C [libsystem_pthread.dylib+0x350d] _pthread_body+0x0 C [libsystem_pthread.dylib+0x2bf9] thread_start+0xd Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j java.lang.Thread.interrupted()Z+4 java.base@14-internal j java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(I)V+0 java.base@14-internal A 7457 java.util.concurrent.CountDownLatch.await()V java.base@14-internal (9 bytes) @ 0x000000012dd7eda4 [0x000000012dd7ed20+0x0000000000000084] j StopAtExit.run()V+11 v ~StubRoutines::call_stub
11-07-2019
It would be informative to run this with GC verification.
08-07-2019
[~kvn] The test in question is Thread/StopAtExit.java which is a stress test that does ThreadStop operations at the end of the JavaThread's life. The purpose of the test is to shake out issues with Thread-SMR logic at the end of the JavaThread's life, but it appears to have found a non-Thread-SMR issue. Short version: The ThreadStop is normal for this test. :-)
08-07-2019
java.lang.Thread.interrupted() was deoptimized before this happened: Event: 0.310 Thread 0x00007ff5f011a000 Uncommon trap: trap_request=0xffffff8f fr.pc=0x00007ff63d8fd31a relative=0x000000000000017a Event: 0.310 Thread 0x00007ff5f011a000 Uncommon trap: reason=constraint action=none pc=0x00007ff63d8fd31a method=java.lang.Thread.interrupted()Z @ 4 jvmci Event: 0.310 Thread 0x00007ff5f011a000 DEOPT PACKING pc=0x00007ff63d8fd31a sp=0x00007ff621bfa730 Event: 0.310 Thread 0x00007ff5f011a000 DEOPT UNPACKING pc=0x00007ff644b87313 sp=0x00007ff621bf9b90 mode 3 There was also request to stop this thread (if I read it correctly): Event: 0.310 Thread 0x00007ff65c8ef800 JVM_StopThread thread JavaThread 0x00007ff5f011a000 as oop 0x00000007579c1f38 [exception 0x00007ff621dfbf78] and we have next events: Event: 0.310 Thread 0x00007ff5f0118800 Thread exited: 0x00007ff5f0118800 Event: 0.310 Thread 0x00007ff5f011a000 Thread added: 0x00007ff5f011a000 Event: 0.310 Protecting memory [0x00007ff621afb000,0x00007ff621aff000] with protection modes 0 Event: 0.310 Executing VM operation: ThreadStop Event: 0.310 Executing VM operation: ThreadStop done Event: 0.310 Executing VM operation: ThreadStop Event: 0.310 Protecting memory [0x00007ff6658c6000,0x00007ff6658c7000] with protection modes 7
08-07-2019
There are currently 8 sightings of this failure mode in Mach5. All of those failures are on Linux and all are AOT runs. There is one failure of this test on Solaris SPARC, but it is not the same failure mode (and it's a personal Mach5 job). I'm moving this bug from hotspot/runtime -> hotspot/compiler for retriage as a possible AOT bug.
06-07-2019
Forgot to show what java.lang.Thread.interrupted() is: src/java.base/share/classes/java/lang/Thread.java: public static boolean interrupted() { return currentThread().isInterrupted(true); } <snip> @HotSpotIntrinsicCandidate private native boolean isInterrupted(boolean ClearInterrupted); so there might be something "interesting" in the native isInterrupted()...
05-07-2019
The InterpreterRuntime::resolve_invoke() code looks like this: src/hotspot/share/interpreter/interpreterRuntime.cpp: void InterpreterRuntime::resolve_invoke(JavaThread* thread, Bytecodes::Code bytecode) { Thread* THREAD = thread; LastFrameAccessor last_frame(thread); // extract receiver from the outgoing argument list if necessary Handle receiver(thread, NULL); if (bytecode == Bytecodes::_invokevirtual || bytecode == Bytecodes::_invokeinterface || bytecode == Bytecodes::_invokespecial) { ResourceMark rm(thread); methodHandle m (thread, last_frame.method()); Bytecode_invoke call(m, last_frame.bci()); Symbol* signature = call.signature(); receiver = Handle(thread, last_frame.callee_receiver(signature)); assert(Universe::heap()->is_in_reserved_or_null(receiver()), "sanity check"); assert(receiver.is_null() || !Universe::heap()->is_in_reserved(receiver->klass()), "sanity check"); } There are only two Handles in the function. Can't be the first one since we pass a NULL oop parameter, so it must be this one: receiver = Handle(thread, last_frame.callee_receiver(signature)); so what would cause last_frame.callee_receiver(signature) to return a bad oop?
05-07-2019
According to the stack trace, the test is in an await() call: Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j java.lang.Thread.interrupted()Z+4 java.base@13-ea j java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt()Z+4 java.base@13-ea j java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(I)V+55 java.base@13-ea A 7649 java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(I)V java.base@13-ea (28 bytes) @ 0x00007ff63d9011e4 [0x00007ff63d900f20+0x00000000000002c4] A 7599 java.util.concurrent.CountDownLatch.await()V java.base@13-ea (9 bytes) @ 0x00007ff63a533024 [0x00007ff63a532fa0+0x0000000000000084] j StopAtExit.run()V+11 and that corresponds to this part of the test: public void run() { try { // Tell main thread we have started. startSyncObj.countDown(); try { // Wait for main thread to interrupt us so we // can race to exit. exitSyncObj.await(); } catch (InterruptedException e) { // ignore because we expect one } } catch (ThreadDeath td) { // ignore because we're testing Thread.stop() which throws it } catch (NoClassDefFoundError ncdfe) { // ignore because we're testing Thread.stop() which can cause it } } So we are not even in test code... the last Java frames are here: j java.lang.Thread.interrupted()Z+4 java.base@13-ea j java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt()Z+4 java.base@13-ea and here's where the thread stack from the hs_err_pid shows us to be: V [libjvm.so+0xd1aa00] HandleArea::allocate_handle(oop)+0x160 V [libjvm.so+0x7f21cf] Handle::Handle(Thread*, oop)+0x9f V [libjvm.so+0xde2538] InterpreterRuntime::resolve_invoke(JavaThread*, Bytecodes::Code)+0x318 V [libjvm.so+0xde5273] InterpreterRuntime::resolve_from_cache(JavaThread*, Bytecodes::Code)+0x133 j java.lang.Thread.interrupted()Z+4 java.base@13-ea j java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt()Z+4 java.base@13-ea So the call to java.lang.Thread.interrupted() resulted in an InterpreterRuntime::resolve_from_cache() call which resulted in an InterpreterRuntime::resolve_invoke() call which tried to create a Handle. That Handle creation attempted resulted in the assertion failure: assert(oopDesc::is_oop(obj)) failed: not an oop: 0x000000080072397c Going to have to take a closer look at InterpreterRuntime::resolve_from_cache() and InterpreterRuntime::resolve_invoke().
05-07-2019
ILW = HLH = P2
02-07-2019
Here's a snippet of the hs_err_pid file: --------------- T H R E A D --------------- Current thread (0x00007ff5f011a000): JavaThread "Thread-14" [_thread_in_vm, id=442, stack(0x00007ff621afb000,0x00007ff621bfc000)] Stack: [0x00007ff621afb000,0x00007ff621bfc000], sp=0x00007ff621bfa430, free space=1021k Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0xd1aa00] HandleArea::allocate_handle(oop)+0x160 V [libjvm.so+0x7f21cf] Handle::Handle(Thread*, oop)+0x9f V [libjvm.so+0xde2538] InterpreterRuntime::resolve_invoke(JavaThread*, Bytecodes::Code)+0x318 V [libjvm.so+0xde5273] InterpreterRuntime::resolve_from_cache(JavaThread*, Bytecodes::Code)+0x133 j java.lang.Thread.interrupted()Z+4 java.base@13-ea j java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt()Z+4 java.base@13-ea j java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(I)V+55 java.base@13-ea A 7649 java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(I)V java.base@13-ea (28 bytes) @ 0x00007ff63d9011e4 [0x00007ff63d900f20+0x00000000000002c4] A 7599 java.util.concurrent.CountDownLatch.await()V java.base@13-ea (9 bytes) @ 0x00007ff63a533024 [0x00007ff63a532fa0+0x0000000000000084] j StopAtExit.run()V+11 v ~StubRoutines::call_stub V [libjvm.so+0xdf353a] JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x6ea V [libjvm.so+0xdf05af] JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x33f V [libjvm.so+0xdf07ca] JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, Thread*)+0xca V [libjvm.so+0xf39f51] thread_entry(JavaThread*, Thread*)+0x91 V [libjvm.so+0x16cac3a] JavaThread::thread_main_inner()+0x26a V [libjvm.so+0x16d3327] JavaThread::run()+0x227 V [libjvm.so+0x16d0396] Thread::call_run()+0xf6 V [libjvm.so+0x13ee5ee] thread_native_entry(Thread*)+0x10e Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j java.lang.Thread.interrupted()Z+4 java.base@13-ea j java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt()Z+4 java.base@13-ea j java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(I)V+55 java.base@13-ea A 7649 java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(I)V java.base@13-ea (28 bytes) @ 0x00007ff63d9011e4 [0x00007ff63d900f20+0x00000000000002c4] A 7599 java.util.concurrent.CountDownLatch.await()V java.base@13-ea (9 bytes) @ 0x00007ff63a533024 [0x00007ff63a532fa0+0x0000000000000084] j StopAtExit.run()V+11 v ~StubRoutines::call_stub I'm attaching the full hs_err_pid file...
29-06-2019
I'm definitely interested... I wrote the test...
28-06-2019