JDK-8239474 : Lots of compiler/aot tests crash VM with -XX:+VerifyOops
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 11,15
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2020-02-19
  • Updated: 2020-06-30
  • Resolved: 2020-06-30
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 15
15Resolved
Related Reports
Duplicate :  
JDK-8209961 - [AOT] crash in Graal stub when -XX:+VerifyOops is used
Description
(Synopsis is provisional, feel free to change after root cause is found)

Run this, reproduces reliably.

$ CONF=linux-x86_64-server-fastdebug make run-test TEST=compiler/aot TEST_VM_OPTS="-XX:+VerifyOops"

==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR   
>> jtreg:test/hotspot/jtreg/compiler/aot                67    33    34     0 

Example hs_err:

# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007fc2830075b5, pid=16633, tid=16658
#
# JRE version: OpenJDK Runtime Environment (15.0) (fastdebug build 15-internal+0-adhoc.shade.jdk-jdk)
# Java VM: OpenJDK 64-Bit Server VM (fastdebug 15-internal+0-adhoc.shade.jdk-jdk, mixed mode, aot, tiered, g1 gc, linux-amd64)
# Problematic frame:
# v  ~RuntimeStub::AOT Stub<resolve_string_by_symbol(Word,Word)Object>
#

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

Current thread (0x00007fc29cde0800):  JavaThread "MainThread" [_thread_in_Java, id=16658, stack(0x00007fc166dbc000,0x00007fc166ebd000)]

Stack: [0x00007fc166dbc000,0x00007fc166ebd000],  sp=0x00007fc166ebac60,  free space=1019k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
v  ~RuntimeStub::AOT Stub<resolve_string_by_symbol(Word,Word)Object>
A 3  compiler.aot.SharedUsageTest.<clinit>()V (13 bytes) @ 0x00007fc282ffa5c0 [0x00007fc282ffa220+0x00000000000003a0]
v  ~StubRoutines::call_stub
V  [libjvm.so+0xc3881c]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x71c
V  [libjvm.so+0xbf6e1f]  InstanceKlass::call_class_initializer(Thread*)+0x1af
V  [libjvm.so+0xbf983c]  InstanceKlass::initialize_impl(Thread*)+0x5ec
V  [libjvm.so+0xbf9d53]  InstanceKlass::initialize(Thread*)+0x83
V  [libjvm.so+0x1385c9f]  invoke(InstanceKlass*, methodHandle const&, Handle, bool, objArrayHandle, BasicType, objArrayHandle, bool, Thread*) [clone .constprop.128]+0x8f
V  [libjvm.so+0x1387886]  Reflection::invoke_method(oop, Handle, objArrayHandle, Thread*)+0x196
V  [libjvm.so+0xdc07b6]  JVM_InvokeMethod+0x1f6
j  jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Ljava/lang/reflect/Method;Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+0 java.base@15-internal
j  jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+100 java.base@15-internal
j  jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+6 java.base@15-internal
j  java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+59 java.base@15-internal
j  com.sun.javatest.regtest.agent.MainWrapper$MainThread.run()V+172
j  java.lang.Thread.run()V+11 java.base@15-internal
v  ~StubRoutines::call_stub
V  [libjvm.so+0xc3881c]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x71c
V  [libjvm.so+0xc3ce85]  JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, Thread*)+0x495
V  [libjvm.so+0xda1ce3]  thread_entry(JavaThread*, Thread*)+0xa3
V  [libjvm.so+0x168a126]  JavaThread::thread_main_inner()+0x206
V  [libjvm.so+0x168ef56]  Thread::call_run()+0xf6
V  [libjvm.so+0x128c5ce]  thread_native_entry(Thread*)+0x10e
Comments
It looks to me +VerifyOops is pretty stable. Apart from this AOT failure and some odd failure in C1 (JDK-8239477), there are no failures in tier{1,2,3} Linux x86_64 in both jdk/jdk and jdk-updates/jdk11u. I am actually considering to put additional configuration for +VerifyOops in nightly/weekly testing pipelines.
23-02-2020
[~shade], VerifyOops was(is?) known to be unstable and unreliable (as in causing lots of false-positive), so we (Oracle) reduced testing we do w/ this flag enabled; so I'm wondering how stable reliable it's your experiments.
21-02-2020
[~dlong] reported crash w/ AOT and VerifyOops some time ago (JDK-8209961).
21-02-2020
ILW = Oop verification fails with AOT code (verification does not support AOT yet), with AOT enabled, disable AOT = LHM = P4
21-02-2020
ForeignCallSnippets.verifyObject() counts the number of verified oops by incrementing StubRoutines::_verify_oop_count. The address of this counter is just baked into the code (which is normal for JIT) but it obviously won't work with AOT. Indirection (through GraalHotSpotVMConfigNode) is required to make it work.
20-02-2020