JDK-8261395 : C1 crash "cannot make java calls from the native compiler"
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 15.0.2
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: linux_redhat_6.0
  • CPU: x86_64
  • Submitted: 2021-02-05
  • Updated: 2025-01-24
  • Resolved: 2021-05-12
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 JDK 17
15.0.4Fixed 17 b22Fixed
Related Reports
Relates :  
JDK-8217765 - Internal Error (javaCalls.cpp:61) guarantee(thread->can_call_java()) failed
Relates :  
JDK-8269135 - TestDifferentProtectionDomains runs into timeout in client VM
Description
ADDITIONAL SYSTEM INFORMATION :
Fedora Linux 33, Java 15.0.2+7

A DESCRIPTION OF THE PROBLEM :
When running IntelliJ to develop in the JDK, I get quite frequent crashes in C1 when it compiles com/intellij/codeInspection/sameParameterValue/SameParameterValueInspection$LocalSameParameterValueInspection$1

This happend with Fedora Java, AdoptOpenJDK as well as official Oracle OpenJDK builds.

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (javaCalls.cpp:60), pid=6248, tid=6261
#  guarantee(thread->can_call_java()) failed: cannot make java calls from the native compiler
#
# JRE version: OpenJDK Runtime Environment (15.0.2+7) (build 15.0.2+7-27)
# Java VM: OpenJDK 64-Bit Server VM (15.0.2+7-27, mixed mode, sharing, tiered, compressed oops, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x773869]  JavaCallWrapper::JavaCallWrapper(methodHandle const&, Handle, JavaValue*, Thread*)+0x1e9
#
# Core dump will be written. Default location: Core dumps may be processed with "/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h" (or dumping to /home/ce/core.6248)
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp
#

---------------  S U M M A R Y ------------

Command Line: -Xms128m -Xmx4096m -XX:SoftRefLRUPolicyMSPerMB=50 -ea -DXX:CompileCommand=exclude,com/intellij/codeInspection/sameParameterValue/SameParameterValueInspection$LocalSameParameterValueInspection$1 -Dsun.io.useCanonPrefixCache=false -Djava.net.preferIPv4Stack=true -Djdk.http.auth.tunneling.disabledSchemes="" -XX:+HeapDumpOnOutOfMemoryError -XX:-OmitStackTraceInFastThrow -Djdk.attach.allowAttachSelf -Dkotlinx.coroutines.debug=off -Djdk.module.illegalAccess.silent=true -Dsun.java2d.renderer=sun.java2d.marlin.MarlinRenderingEngine -Dsun.tools.attach.tmp.only=true -Dsun.java2d.uiScale.enabled=true -Dsun.java2d.uiScale=1 -XX:ErrorFile=/home/ce/java_error_in_idea_%p.log -XX:HeapDumpPath=/home/ce/java_error_in_idea_.hprof -Didea.vendor.name=JetBrains -Didea.paths.selector=IntelliJIdea2020.3 -Djb.vmOptionsFile=/home/ce/.config/JetBrains/IntelliJIdea2020.3/idea64.vmoptions -Didea.jre.check=true com.intellij.idea.Main

Host: AMD Ryzen 5 4500U with Radeon Graphics, 6 cores, 14G, Fedora release 33 (Thirty Three)
Time: Fri Feb  5 09:24:15 2021 CET elapsed time: 4647.815840 seconds (0d 1h 17m 27s)

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

Current thread (0x00007f53e4116740):  JavaThread "C1 CompilerThread0" daemon [_thread_in_vm, id=6261, stack(0x00007f53ab3fc000,0x00007f53ab4fd000)]


Current CompileTask:
C1:4647815 71249       3       com.intellij.codeInspection.sameParameterValue.SameParameterValueInspection$LocalSameParameterValueInspection$1::visitMethod (362 bytes)

Stack: [0x00007f53ab3fc000,0x00007f53ab4fd000],  sp=0x00007f53ab4fa1c0,  free space=1016k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x773869]  JavaCallWrapper::JavaCallWrapper(methodHandle const&, Handle, JavaValue*, Thread*)+0x1e9
V  [libjvm.so+0x774020]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x100
V  [libjvm.so+0x77589b]  JavaCalls::call_special(JavaValue*, Handle, Klass*, Symbol*, Symbol*, Handle, Handle, Thread*)+0x19b
V  [libjvm.so+0xca429f]  SystemDictionary::validate_protection_domain(InstanceKlass*, Handle, Handle, Thread*)+0x20f
V  [libjvm.so+0xca6c08]  SystemDictionary::resolve_instance_class_or_null(Symbol*, Handle, Handle, Thread*)+0x598
V  [libjvm.so+0xca928e]  SystemDictionary::resolve_or_fail(Symbol*, Handle, Handle, bool, Thread*)+0x5e
V  [libjvm.so+0x558658]  ConstantPool::klass_at_impl(constantPoolHandle const&, int, bool, Thread*)+0xe8
V  [libjvm.so+0x753428]  InstanceKlass::has_nest_member(InstanceKlass*, Thread*) const+0x308
V  [libjvm.so+0x753fae]  InstanceKlass::nest_host(Thread*) [clone .part.0]+0x50e
V  [libjvm.so+0x7541b0]  InstanceKlass::has_nestmate_access_to(InstanceKlass*, Thread*)+0x50
V  [libjvm.so+0xbd080b]  Reflection::verify_member_access(Klass const*, Klass const*, Klass const*, AccessFlags, bool, bool, Thread*)+0x1cb
V  [libjvm.so+0x9c95a1]  LinkResolver::check_method_accessability(Klass*, Klass*, Klass*, methodHandle const&, Thread*)+0x61
V  [libjvm.so+0x9ca12e]  LinkResolver::resolve_method(LinkInfo const&, Bytecodes::Code, Thread*)+0x31e
V  [libjvm.so+0x9cccda]  LinkResolver::linktime_resolve_virtual_method(LinkInfo const&, Thread*)+0x2a
V  [libjvm.so+0x9ccf53]  LinkResolver::linktime_resolve_virtual_method_or_null(LinkInfo const&)+0x33
V  [libjvm.so+0x4a7e89]  ciEnv::lookup_method(ciInstanceKlass*, ciKlass*, Symbol*, Symbol*, Bytecodes::Code, constantTag)+0xb9
V  [libjvm.so+0x4a8088]  ciEnv::get_method_by_index_impl(constantPoolHandle const&, int, Bytecodes::Code, ciInstanceKlass*)+0x118
V  [libjvm.so+0x4c6d1d]  ciBytecodeStream::get_method(bool&, ciSignature**)+0x10d
V  [libjvm.so+0x3eb116]  GraphBuilder::invoke(Bytecodes::Code)+0x36
V  [libjvm.so+0x3ecccb]  GraphBuilder::iterate_bytecodes_for_block(int)+0x5cb
V  [libjvm.so+0x3ef20d]  GraphBuilder::iterate_all_blocks(bool)+0x6d
V  [libjvm.so+0x3f12e6]  GraphBuilder::GraphBuilder(Compilation*, IRScope*)+0x316
V  [libjvm.so+0x3f6cea]  IRScope::IRScope(Compilation*, IRScope*, int, ciMethod*, int, bool)+0x1ca
V  [libjvm.so+0x3f6da3]  IR::IR(Compilation*, ciMethod*, int)+0xa3
V  [libjvm.so+0x3d1273]  Compilation::build_hir() [clone .part.0]+0x163
V  [libjvm.so+0x3d21cc]  Compilation::compile_java_method()+0x3bc
V  [libjvm.so+0x3d2338]  Compilation::compile_method()+0x108
V  [libjvm.so+0x3d27ac]  Compilation::Compilation(AbstractCompiler*, ciEnv*, ciMethod*, int, BufferBlob*, DirectiveSet*)+0x20c
V  [libjvm.so+0x3d32fd]  Compiler::compile_method(ciEnv*, ciMethod*, int, DirectiveSet*)+0xad
V  [libjvm.so+0x536388]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0xd18
V  [libjvm.so+0x536dd8]  CompileBroker::compiler_thread_loop()+0x4e8
V  [libjvm.so+0xcf2d6e]  JavaThread::thread_main_inner()+0xde
V  [libjvm.so+0xcf7bdd]  Thread::call_run()+0xfd
V  [libjvm.so+0xb4ac87]  thread_native_entry(Thread*)+0xe7

END.


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Run IntelliJ with a large Project

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
C1 should compile without aborting, or bail out
ACTUAL -
C1 crashes with an internal error: 

#  Internal Error (javaCalls.cpp:60), pid=6248, tid=6261
#  guarantee(thread->can_call_java()) failed: cannot make java calls from the native compiler

CUSTOMER SUBMITTED WORKAROUND :
run with -XX:CompileCommand=exclude,com/intellij/codeInspection/sameParameterValue/SameParameterValueInspection$LocalSameParameterValueInspection$1

FREQUENCY : always
Comments
Fix Request (15u): The issue is seen in the wild with Idea, would be nice to have it backported into jdk15u. Testing: the testcase, tier1.
20-05-2021
ojdk13u doesn't crash on provided testcase, setting 13-na
20-05-2021
Changeset: e828a939 Author: David Holmes <dholmes@openjdk.org> Date: 2021-05-12 05:21:58 +0000 URL: https://git.openjdk.java.net/jdk/commit/e828a939a8155a3b4ab26811a405bb4e4b2b99e8
12-05-2021
[~iklam] created a reproducer (thanks!) and it turns to be trivially easy (even if semantically meaningless) to gives classes different protection domains. It is unclear what valid reason may exist to put an enclosing class and its nested class in different protection domains, but it is allowed. Recent changes to the code in 17 mean that this failure is now only seen if a Security Manager is installed (though a debug build always fails). The fix allows us to properly check that the nest member class is loaded (which it is) without pretending to go through the class loading process that might result in executing Java code.
11-05-2021
After offline discussion with Coleen and Ioi we have a proposed fix, and will also try to construct a reproducer.
06-05-2021
[~coleenp] both classes are fully loaded as per my earlier comments. The problem appears to be that the klass present in the nesthost member's array has a different PD to the actual nest member klass we are validating. I'm awaiting for logging data to hopefully show how this arises as it should not be possible.
03-05-2021
So this is intermittent? What are the other threads doing? One of the things we do that has always seemed suspicious is that we add the klass to the dictionary, mark it is_loaded and then check the protection domain before returning from resolve_instance_class_or_null. Could the class be loading but not have checked protection domain yet, which is why it's not yet in the constant pool?
01-05-2021
[~iklam] Thanks for the suggestion. At this stage until I know how we somehow appear to get a second protection domain associated with one class I'm not actively trying to find a workaround. It isn't yet obvious to me that if we allowed the compiler-thread to proceed that k2 would indeed equal k - it _should_ but then it should not be possible to change PD's either, so this classloader may be doing very strange things.
01-05-2021
Maybe we can fix it by: // private: called to verify that k is a static member of this nest. // We know that k is an instance class in the same package and hence the // same classloader. bool InstanceKlass::has_nest_member(InstanceKlass* k, TRAPS) const { assert(class_loader_data() == k->class_loader_data(), "must be"); ... if (_constants->tag_at(cp_index).is_klass()) { .... } else { Symbol* name = _constants->klass_name_at(cp_index); if (name == k->name()) { log_trace(class, nestmates)("- Found it at nest_members[%d] => cp[%d]", i, cp_index); constantPoolHandle(THREAD, _constants); Klass* k2 = ConstantPool::klass_at_if_loaded(cp, cp_index); if (k2 == k) { log_trace(class, nestmates)("- class is listed as a nest member"); return true; } else { // For some reason, we have JVM_CONSTANT_UnresolvedClassInError in the host class. assert(k2 == NULL, "a classloader cannot define two classes of the same name"); log_trace(class, nestmates)(" - host class has UnresolvedClassInError"); return false; } } ....
30-04-2021
I am running IntelliJ with tracing on, as soon as it happens again I'll report back.
30-04-2021
Pinging [~ceisserer]. Without understanding how this arises it is hard to determine a suitable fix/workaround.
30-04-2021
[~ceisserer] Just as a sanity check could you try reproducing with -Xlog:protectiondomain=trace, thanks.
14-04-2021
Thanks [~ceisserer]! From the log, focusing on the classes in the problem area: [33,155s][debug][protectiondomain] class loader: a 'com/intellij/ide/plugins/cl/PluginClassLoader'{0x0000000705bb9858} protection domain: a 'java/security/ProtectionDomain'{0x0000000739aefd70} loading: 'com/intellij/codeInspection/sameParameterValue/SameParameterValueInspection$LocalSameParameterValueInspection' [33,156s][debug][protectiondomain] class loader: a 'com/intellij/ide/plugins/cl/PluginClassLoader'{0x0000000705bb9858} protection domain: a 'java/security/ProtectionDomain'{0x0000000739aefd70} loading: 'com/intellij/codeInspection/sameParameterValue/SameParameterValueInspection$2' [33,158s][debug][protectiondomain] class loader: a 'com/intellij/ide/plugins/cl/PluginClassLoader'{0x0000000705bb9858} protection domain: a 'java/security/ProtectionDomain'{0x0000000739af7840} loading: 'com/intellij/codeInspection/sameParameterValue/SameParameterValueInspection$LocalSameParameterValueInspection$1' [33,160s][trace][class,nestmates ] Type com.intellij.codeInspection.sameParameterValue.SameParameterValueInspection is not part of a nest: setting nest-host to self [33,160s][trace][class,nestmates ] Resolving nest-host of com.intellij.codeInspection.sameParameterValue.SameParameterValueInspection$LocalSameParameterValueInspection using cp entry for com/intellij/codeInspection/sameParameterValue/SameParameterValueInspection [33,160s][debug][protectiondomain] Checking package access [33,160s][debug][protectiondomain] class loader: a 'com/intellij/ide/plugins/cl/PluginClassLoader'{0x0000000705bb9858} protection domain: a 'java/security/ProtectionDomain'{0x0000000739af7840} loading: 'com/intellij/codeInspection/sameParameterValue/SameParameterValueInspection' [33,160s][debug][protectiondomain] granted [33,160s][trace][class,nestmates ] Checking nest membership of com.intellij.codeInspection.sameParameterValue.SameParameterValueInspection$LocalSameParameterValueInspection in com.intellij.codeInspection.sameParameterValue.SameParameterValueInspection [33,160s][trace][class,nestmates ] - class is listed at nest_members[0] => cp[71] [33,160s][trace][class,nestmates ] Resolved nest-host of com.intellij.codeInspection.sameParameterValue.SameParameterValueInspection$LocalSameParameterValueInspection to com.intellij.codeInspection.sameParameterValue.SameParameterValueInspection [33,160s][trace][class,nestmates ] Class com.intellij.codeInspection.sameParameterValue.SameParameterValueInspection does have nestmate access to com.intellij.codeInspection.sameParameterValue.SameParameterValueInspection$LocalSameParameterValueInspection [33,414s][debug][protectiondomain] class loader: a 'com/intellij/ide/plugins/cl/PluginClassLoader'{0x0000000705bb9858} protection domain: a 'java/security/ProtectionDomain'{0x00000007397e9c88} loading: 'com/intellij/codeInspection/sameParameterValue/SameParameterValueInspection$LocalSameParameterValueInspection' [33,415s][debug][protectiondomain] class loader: a 'com/intellij/ide/plugins/cl/PluginClassLoader'{0x0000000705bb9858} protection domain: a 'java/security/ProtectionDomain'{0x00000007397e9c88} loading: 'com/intellij/codeInspection/sameParameterValue/SameParameterValueInspection' [1213,816s][trace][class,nestmates ] Resolving nest-host of com.intellij.codeInspection.sameParameterValue.SameParameterValueInspection$LocalSameParameterValueInspection$1 using cp entry for com/intellij/codeInspection/sameParameterValue/SameParameterValueInspection [1213,816s][trace][class,nestmates ] Checking nest membership of com.intellij.codeInspection.sameParameterValue.SameParameterValueInspection$LocalSameParameterValueInspection$1 in com.intellij.codeInspection.sameParameterValue.SameParameterValueInspection [1213,816s][trace][class,nestmates ] - Found it at nest_members[1] => cp[215] [1213,816s][debug][protectiondomain] Checking package access [1213,816s][debug][protectiondomain] class loader: a 'com/intellij/ide/plugins/cl/PluginClassLoader'{0x0000000705bb9858} protection domain: a 'java/security/ProtectionDomain'{0x000000071ec67f88} loading: 'com/intellij/codeInspection/sameParameterValue/SameParameterValueInspection$LocalSameParameterValueInspection$1' # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (javaCalls.cpp:60), pid=19097, tid=19110 # guarantee(thread->can_call_java()) failed: cannot make java calls from the native compiler We can see that the same classloader is always reported: a 'com/intellij/ide/plugins/cl/PluginClassLoader'{0x0000000705bb9858 But the protection domains are changing. In particular we see: [33,158s][debug][protectiondomain] class loader: a 'com/intellij/ide/plugins/cl/PluginClassLoader'{0x0000000705bb9858} protection domain: a 'java/security/ProtectionDomain'{0x0000000739af7840} loading: 'com/intellij/codeInspection/sameParameterValue/SameParameterValueInspection$LocalSameParameterValueInspection$1' then at the crash point: [1213,816s][debug][protectiondomain] class loader: a 'com/intellij/ide/plugins/cl/PluginClassLoader'{0x0000000705bb9858} protection domain: a 'java/security/ProtectionDomain'{0x000000071ec67f88} loading: 'com/intellij/codeInspection/sameParameterValue/SameParameterValueInspection$LocalSameParameterValueInspection$1' so the same class is somehow related to different protection domains. And that second protection domain is not referenced anywhere else. So in SystemDictionary::find_instance_class_or_null when we execute: InstanceKlass* probe = dictionary->find(d_hash, name, protection_domain); if (probe != NULL) return probe; the probe is NULL, even though the class is loaded, because the protection domain was not found in the pd_set for this class. So we then continue to "load" the class, but when we reach: MutexLocker mu(THREAD, SystemDictionary_lock); InstanceKlass* check = find_class(d_hash, name, dictionary); if (check != NULL) { // InstanceKlass is already loaded, so just return it class_has_been_loaded = true; k = check; we do find the class in the dictionary because it was actually already loaded. So we then hit: // Check the protection domain has the right access if (dictionary->is_valid_protection_domain(d_hash, name, protection_domain)) { return k; } which again fails (this is the same check done inside dictionary->find()), so we then call: validate_protection_domain(k, class_loader, protection_domain, CHECK_NULL); which is where the Java call happens and we hit the guarantee. Note that in a debug build we would fail sooner in resolve_instance_class_or_null when we hit: assert(THREAD->can_call_java(), "can not load classes with compiler thread: class=%s, classloader=%s", name->as_C_string(), class_loader.is_null() ? "null" : class_loader->klass()->name()->as_C_string()); which happens after the failed find() call. So we have a significant problem here. The compiler thread cannot execute beyond the failed find() call, but it has to get the correct answer for the nestmate access check. It may be the that classloader here is doing something wrong in regards to its use of protection domains but we still must not crash this way.
14-04-2021
just happend twice again, please find the output of protectiondomain-logging in logs_protectiondomain.zip. The corresponding hs_err files are: java_error_in_idea_19097.log and java_error_in_idea_3342.log
13-04-2021
Yes that SEGV seems unrelated.
06-04-2021
sorry, the crash with nestmate-tracing indeed seems to be another issue in C2, I attached the hs_err regardless. Thanks for the hint, I'll try to reproduce with protectiondomain=debug.
06-04-2021
[~ceisserer] That log shows a crash due to SEGV not the guarantee failure reported in this bug! Can you share the hs_err log file for that crash please? Can you also try running with -Xlog:protectiondomain=debug, thanks.
05-04-2021
I am the original reporter of this issue, and was asked by swati to test with "-Xlog:class+nestmates=trace" - please find the resulting log file (hs_log.zip) attached to the bug report.
05-04-2021
Doh! Thanks Coleen I was looking at mainline. Now updated to correct code above.
10-03-2021
[updated to correct 15u code] This is the code we unexpectedly reach: // return if the protection domain in NULL if (protection_domain() == NULL) return k; // Check the protection domain has the right access if (dictionary->is_valid_protection_domain(d_hash, name, protection_domain)) { return k; } // Verify protection domain. If it fails an exception is thrown validate_protection_domain(k, class_loader, protection_domain, CHECK_NULL); So: - PD is not NULL - PD is not valid // Tells whether the initiating class' protection domain can access the klass in this entry bool is_valid_protection_domain(Handle protection_domain) { if (!ProtectionDomainVerification) return true; return protection_domain() == NULL ? true : contains_protection_domain(protection_domain()); } then: bool DictionaryEntry::contains_protection_domain(oop protection_domain) const { // Lock the pd_set list. This lock cannot safepoint since the caller holds // a Dictionary entry, which can be moved if the Dictionary is resized. MutexLocker ml(ProtectionDomainSet_lock, Mutex::_no_safepoint_check_flag); if (protection_domain == instance_klass()->protection_domain()) { // Succeeds trivially return true; } for (ProtectionDomainEntry* current = pd_set(); current != NULL; current = current->next()) { if (current->object_no_keepalive() == protection_domain) return true; } return false; } so we need to see what the values of the PDs actually are. Need to use -Xlog:protectiondomain=debug to hopefully see what we need.
10-03-2021
This is somewhat new code. In JDK 15 we called checkPackageAccess even if there isn't a security manager.
10-03-2021
Hello. Just FYI, we've got similar response from one of our users of zulu community version: I'll try to get "-Xlog:class+nestmates=trace" crash logs there. # Internal Error (javaCalls.cpp:60), pid=309279, tid=309292 # guarantee(thread->can_call_java()) failed: cannot make java calls from the native compiler # # JRE version: OpenJDK Runtime Environment Zulu15.29+15-CA (15.0.2+7) (build 15.0.2+7) # Java VM: OpenJDK 64-Bit Server VM Zulu15.29+15-CA (15.0.2+7, mixed mode, sharing, tiered, compressed oops, g1 gc, linux-amd64) # Problematic frame: # V [libjvm.so+0x7df6c4] JavaCallWrapper::JavaCallWrapper(methodHandle const&, Handle, JavaValue*, Thread*)+0x1c4 ... Current thread (0x00007f8ab817a220): JavaThread "C1 CompilerThread0" daemon [_thread_in_vm, id=309292, stack(0x00007f8a7f184000,0x00007f8a7f285000)] Current CompileTask: C1: 501431 65222 2 com.intellij.codeInspection.sameParameterValue.SameParameterValueInspection$LocalSameParameterValueInspection$1::visitMethod (362 bytes) Stack: [0x00007f8a7f184000,0x00007f8a7f285000], sp=0x00007f8a7f282060, free space=1016k Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x7df6c4] JavaCallWrapper::JavaCallWrapper(methodHandle const&, Handle, JavaValue*, Thread*)+0x1c4 V [libjvm.so+0x7e2bb3] JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x183 V [libjvm.so+0x7e0fcc] JavaCalls::call_special(JavaValue*, Handle, Klass*, Symbol*, Symbol*, Handle, Handle, Thread*)+0x1cc V [libjvm.so+0xdffe6d] SystemDictionary::validate_protection_domain(InstanceKlass*, Handle, Handle, Thread*)+0x20d V [libjvm.so+0xe02a4c] SystemDictionary::resolve_instance_class_or_null(Symbol*, Handle, Handle, Thread*)+0xb1c V [libjvm.so+0xe02bfa] SystemDictionary::resolve_instance_class_or_null_helper(Symbol*, Handle, Handle, Thread*)+0x2a V [libjvm.so+0xe03fce] SystemDictionary::resolve_or_fail(Symbol*, Handle, Handle, bool, Thread*)+0x2e V [libjvm.so+0x5994df] ConstantPool::klass_at_impl(constantPoolHandle const&, int, bool, Thread*)+0xdf V [libjvm.so+0x7c0040] ConstantPool::klass_at(int, Thread*)+0x60 V [libjvm.so+0x7ba577] InstanceKlass::has_nest_member(InstanceKlass*, Thread*) const+0x397 V [libjvm.so+0x7bc41e] InstanceKlass::nest_host(Thread*) [clone .part.349]+0x3ae V [libjvm.so+0x7bc57c] InstanceKlass::has_nestmate_access_to(InstanceKlass*, Thread*)+0x4c V [libjvm.so+0xc5d027] Reflection::verify_member_access(Klass const*, Klass const*, Klass const*, AccessFlags, bool, bool, Thread*)+0x207 V [libjvm.so+0xa18ed1] LinkResolver::check_method_accessability(Klass*, Klass*, Klass*, methodHandle const&, Thread*)+0x61 V [libjvm.so+0xa19b26] LinkResolver::resolve_method(LinkInfo const&, Bytecodes::Code, Thread*)+0x3e6 V [libjvm.so+0xa1ccf7] LinkResolver::linktime_resolve_virtual_method(LinkInfo const&, Thread*)+0x27 V [libjvm.so+0xa1cf62] LinkResolver::linktime_resolve_virtual_method_or_null(LinkInfo const&)+0x32 V [libjvm.so+0x4d1f0c] ciEnv::get_method_by_index_impl(constantPoolHandle const&, int, Bytecodes::Code, ciInstanceKlass*)+0x3ec V [libjvm.so+0x4d24a0] ciEnv::get_method_by_index(constantPoolHandle const&, int, Bytecodes::Code, ciInstanceKlass*)+0x310 V [libjvm.so+0x4f647e] ciBytecodeStream::get_method(bool&, ciSignature**)+0x11e V [libjvm.so+0x407f93] GraphBuilder::invoke(Bytecodes::Code)+0x33 V [libjvm.so+0x40a2d7] GraphBuilder::iterate_bytecodes_for_block(int)+0x10b7 V [libjvm.so+0x40bd44] GraphBuilder::iterate_all_blocks(bool)+0x174 V [libjvm.so+0x40dba0] GraphBuilder::GraphBuilder(Compilation*, IRScope*)+0x440 V [libjvm.so+0x4116e2] IRScope::IRScope(Compilation*, IRScope*, int, ciMethod*, int, bool)+0x1d2 V [libjvm.so+0x412326] IR::IR(Compilation*, ciMethod*, int)+0xa6 V [libjvm.so+0x3f21f6] Compilation::build_hir() [clone .part.95]+0x166 V [libjvm.so+0x3f2a43] Compilation::compile_java_method()+0x3a3 V [libjvm.so+0x3f2bdf] Compilation::compile_method()+0x12f V [libjvm.so+0x3f303c] Compilation::Compilation(AbstractCompiler*, ciEnv*, ciMethod*, int, BufferBlob*, DirectiveSet*)+0x22c V [libjvm.so+0x3f391e] Compiler::compile_method(ciEnv*, ciMethod*, int, DirectiveSet*)+0xae V [libjvm.so+0x572b8c] CompileBroker::invoke_compiler_on_method(CompileTask*)+0xeec V [libjvm.so+0x573978] CompileBroker::compiler_thread_loop()+0x5b8 V [libjvm.so+0xe5286e] JavaThread::thread_main_inner()+0x1be V [libjvm.so+0xe574af] Thread::call_run()+0xff V [libjvm.so+0xbc91b7] thread_native_entry(Thread*)+0xe7 ... =>0x00007f8ab817a220 JavaThread "C1 CompilerThread0" daemon [_thread_in_vm, id=309292, stack(0x00007f8a7f184000,0x00007f8a7f285000)] ...
09-03-2021
Not diagnosed, just supposition. The only way this can lead to the code in question is if the class had a different Protection Domain. I don't know if that is possible, or if so, under what circumstances. I can't reproduce this so can't get to the bottom of it.
17-02-2021
There is something rather contradictory about throwing a Java exception in a thread that can't execute Java code. I would not recommend trying to use an exception in this manner. Compiler code that may lead to potential Java execution is supposed to be guarded so we don't actually reach that code. If we just threw a VME the higher-level code can't tell whether it was a real VME or whether it simply meant we tried to execute Java code. That aside we have to determine how we get into this seemingly impossible case.
10-02-2021
Or have an alternate version of klass_at that either calls klass_at_impl() or klass_at_noresolve() depending on whether the thread can call java. I thought you diagnosed the case as having a new protection domain that requires checking?
10-02-2021
ILW=HMM=P2
09-02-2021
I wonder if ConstantPool::klass_at_impl() should just throw VME if !Thread->can_call_java() and make the callers deal with it as the compiler calls linktime_resolve_virtual_method_or_null does. We keep running into this with klass_at().
09-02-2021
Just to be clear we are dealing with two already loaded classes classA and classB, where classA is the potential nest-member and classB the nest-host. We iterate the classB nest_members array and check each CP entry to see if it refers to classA. If the cp entry is already resolved then we compare the two classes directly. If the names match then it means the CP slot is not yet resolved, but resolving it cannot require loading a class because classA is already loaded - resolving should simply install a pointer to classA in that CP slot and mark it resolved. If we are triggering classloading then it means the classloader when asked for a class named "classA" is saying "I don't have one of those at the moment so I'll go and look for it" - and that should be impossible because we already have classA. Further, the loaders involved cannot be different at this point because we have a same-package check prior to this code. One possibility is that the code that resolves the class is diverting into the Java call to validate_protection_domain before establishing that the class has already been loaded. But that should not be the case either was we should immediately find the class in the SystemDictionary: { InstanceKlass* probe = dictionary->find(d_hash, name, protection_domain); if (probe != NULL) return probe; } unless there is something different about the protection domain here that would cause the find() to fail.
09-02-2021
Additional information requested from submitter: ============================================ Could you please try to reproduce this issue with "-Xlog:class+nestmates=trace" and share the crash logs. ============================================
09-02-2021
Is it possible for the submitter to reproduce this with -Xlog:class+nestmates=trace?
09-02-2021
The crash is in JavaCallWrapper # Problematic frame: # V [libjvm.so+0x773869] JavaCallWrapper::JavaCallWrapper(methodHandle const&, Handle, JavaValue*, Thread*)+0x1e9 Stack trace looks similar to https://bugs.openjdk.java.net/browse/JDK-8217765 Moving it to Dev team for further analysis!
09-02-2021
Here is the code: bool InstanceKlass::has_nest_member(InstanceKlass* k, TRAPS) const { assert(!is_hidden(), "unexpected hidden class"); if (_nest_members == NULL || _nest_members == Universe::the_empty_short_array()) { if (log_is_enabled(Trace, class, nestmates)) { ResourceMark rm(THREAD); log_trace(class, nestmates)("Checked nest membership of %s in non-nest-host class %s", k->external_name(), this->external_name()); } return false; } if (log_is_enabled(Trace, class, nestmates)) { ResourceMark rm(THREAD); log_trace(class, nestmates)("Checking nest membership of %s in %s", k->external_name(), this->external_name()); } // Check for a resolved cp entry , else fall back to a name check. // We don't want to resolve any class other than the one being checked. for (int i = 0; i < _nest_members->length(); i++) { int cp_index = _nest_members->at(i); if (_constants->tag_at(cp_index).is_klass()) { Klass* k2 = _constants->klass_at(cp_index, THREAD); assert(!HAS_PENDING_EXCEPTION || PENDING_EXCEPTION->is_a(SystemDictionary::VirtualMachineError_klass()), "Exceptions should not be possible here"); if (k2 == k) { log_trace(class, nestmates)("- class is listed at nest_members[%d] => cp[%d]", i, cp_index); return true; } } else { Symbol* name = _constants->klass_name_at(cp_index); if (name == k->name()) { log_trace(class, nestmates)("- Found it at nest_members[%d] => cp[%d]", i, cp_index); // Names match so check actual klass. This may trigger class loading if // it doesn't match though that should be impossible as it means one classloader // has defined two different classes with the same name! A compiler thread won't be // able to perform that loading but we can't exclude the compiler threads from // executing this logic. But it should actually be impossible to trigger loading here. Klass* k2 = _constants->klass_at(cp_index, THREAD); assert(!HAS_PENDING_EXCEPTION || PENDING_EXCEPTION->is_a(SystemDictionary::VirtualMachineError_klass()), "Exceptions should not be possible here"); if (k2 == k) { log_trace(class, nestmates)("- class is listed as a nest member"); return true; } else { // same name but different klass! log_trace(class, nestmates)(" - klass comparison failed!"); // can't have two names the same, so we're done return false; } } } } log_trace(class, nestmates)("- class is NOT a nest member!"); return false; } We seem to be hitting the code prefixed by: // Names match so check actual klass. This may trigger class loading if // it doesn't match though that should be impossible as it means one classloader // has defined two different classes with the same name! A compiler thread won't be // able to perform that loading but we can't exclude the compiler threads from // executing this logic. But it should actually be impossible to trigger loading here. As it notes we can't just check for can_call_Java() here because we can only reject the nestmate access check, which may not be the correct thing to do. That said this should be impossible unless we have a ClassLoader that is not conforming to specification and has loaded the same named class twice.
09-02-2021
The symptoms are very similar to JDK-8217765. Looks like the fix for JDK-8217765 was incomplete.
05-02-2021