Bug ID: JDK-8166277 SIGSEGV in Dependencies::DepStream::argument(int)

Type: Bug
Component: hotspot
Sub-Component: compiler
Affected Version: 9

Priority: P2
Status: Closed
Resolution: Duplicate

Submitted: 2016-09-19
Updated: 2023-07-21
Resolved: 2023-07-21

JDK 10
10Resolved

Test failed with SIGSEGV during adhoc run:
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x0000000209913275, pid=88596, tid=26887
#
# JRE version: Java(TM) SE Runtime Environment (9.0) (fastdebug build 9-internal+0-2016-09-14-185608.mlchung.JDK-8157464-fix)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 9-internal+0-2016-09-14-185608.mlchung.JDK-8157464-fix, compiled mode, tiered, compressed oops, g1 gc, bsd-amd64)
# Problematic frame:
# V  [libjvm.dylib+0x496275]  Dependencies::DepStream::argument(int)+0xc9
#
# Core dump will be written. Default location: /cores/core.88596
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
#

hs_err_pid is attached.

JDK-8190891 should solve this problem, so closing this as a duplicate.
20-11-2017
Nevermind, ciObjectFactory::create_new_metadata() returns the right ci subclass depending on the metadata type.
20-11-2017
I don't see the ciKlass _base_element_klass getting turned into a ciInstanceKlass anywhere.
20-11-2017
[~dlong] Does this line create the ciInstanceKlass for the element klass? // Constructor for loaded object array klasses. ciObjArrayKlass::ciObjArrayKlass(Klass* k) : ciArrayKlass(k) { assert(get_Klass()->is_objArray_klass(), "wrong type"); Klass* element_Klass = get_ObjArrayKlass()->bottom_klass(); _base_element_klass = CURRENT_ENV->get_klass(element_Klass); <== this guy ? assert(_base_element_klass->is_instance_klass() \|\| _base_element_klass->is_type_array_klass(), "bad base klass"); if (dimension() == 1) { _element_klass = _base_element_klass; } else { _element_klass = NULL; } if (!ciObjectFactory::is_initialized()) { assert(_element_klass->is_java_lang_Object(), "only arrays of object are shared"); } } Would it hit the SATB in the ciInstanceKlass constructor for this compilation? The other ciObjArrayKlass passes the element_klass, which already has the reference kept alive. At least that's what I think it does.
20-11-2017
[~coleenp] Sorry, I meant ciObjArrayKlass.
20-11-2017
Is this still reproduceable? I increased the occurrence of SATB barriers with my recent change in this area.
20-11-2017
[~dlong] Isn't ciObjArray producted with ciObject(ciKlass) where the ciKlass is the ciInstanceKlass of the element type? The latter should keep the klass of the ciInstanceKlass alive, if this is the case.
20-11-2017
[~coleenp] I haven't been able to reproduce it, even with an older jdk9 build. It's very rare. I think your recent change does fix all the problems with ciInstanceKlass, but I'm still worried there is a similar problem with ciObjArray still.
20-11-2017
I now believe this is related to ClassUnloadingWithConcurrentMark and is not limited to debug builds. -XX:-ClassUnloadingWithConcurrentMark should be a workaround. updated ILW=crash,any app with class unloading,workaround=HML=P2
19-11-2017
Is this an object resurrection issue? If calls like ciInstanceKlass::unique_concrete_subklass() can resurrect a klass that was previously considered dead, then are we missing a call to G1SATBCardTableModRefBS::enqueue()?
19-11-2017
I found a crash from 5/5/17 with a core dump. We were compiling java.security.CodeSource::matchCerts, and there was a dependency on javasoft/sqe/tests/api/java/lang/ClassLoader/MyCertificate being the only concrete subclass or abstract class java/security/cert/Certificate. Apparently the subclass was unloaded and the ciInstanceKlass failed to keep it alive. At the time of the crash, the subclass appears to be gone from the metadata. It's super class has an empty subclass list. But there is a JNI local jobject for the classloader of the subclass, and it appears to point to a valid old-gen object, so it's a mystery why it was removed from the class hierarchy and metadata. So metadata was zapped but heap objects were not.
18-11-2017
[~vlivanov] Hi Vladimir. I was wondering if I could take this bug, but I'm having trouble reproducing it. It seems like we need methods with dependencies on klasses that are getting unloaded. When I try to reproduce the problem, I only see LambdaForm classes getting unloaded. Also, do you have a root cause already identified?
16-11-2017
updated ILW=crash but only in debug VM (-XX:+VerifyDependencies),two tests,no workaround=LLH=P5
04-10-2016
The above assembly most likely corresponds to assert(result == NULL \|\| result->is_klass() \|\| result->is_method(), "must be"); i.e., line 921 in dependencies.cpp
21-09-2016
Here is the disassembly: 0000000000000000 f6e8 imul %al 0000000000000002 51 push %rcx 0000000000000003 ffff invalid 0000000000000005 ff89df4889c6 dec -0x3976b721(%rcx) 000000000000000b e8a1e4ffff call 0xffffffffffffe4b1 0000000000000010 4889c3 mov %rax, %rbx 0000000000000013 31c0 xor %rax, %rax 0000000000000015 4885db test %rbx, %rbx 0000000000000018 745a jz 0x74 000000000000001a 488b03 mov (%rbx), %rax 000000000000001d 4889df mov %rbx, %rdi failure --> 0000000000000020 ff5008 call 0x8(%rax) # rax is dead metadata 0000000000000023 84c0 test %al, %al 0000000000000025 754a jnz 0x71 0000000000000027 488b03 mov (%rbx), %rax 000000000000002a 4889df mov %rbx, %rdi 000000000000002d ff5010 call 0x10(%rax) 0000000000000030 84c0 test %al, %al 0000000000000032 753d jnz 0x71 0000000000000034 e82344feff call 0xfffffffffffe445c 0000000000000039 84c0 test %al, %al 000000000000003b 740e jz 0x4b 000000000000003d 488d3d invalid So it seems that some of the metadata that has been recorded became invalid (it is zapped to 0xbaadfade).
21-09-2016
ILW=crash,single test,no workaround=HLH=P2
19-09-2016

Duplicate :	JDK-8190891 - Clean up G1 barrier code in compiler interface (ci)
Relates :	JDK-8049421 - G1 Class Unloading after completing a concurrent mark cycle