JDK-8251945 : SIGSEGV in PackageEntry::purge_qualified_exports()
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 11.0.8,11-pool
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2020-08-18
  • Updated: 2022-09-06
  • Resolved: 2020-08-27
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 11
11.0.10-oracle b01Fixed
Related Reports
Duplicate :  
JDK-8246467 - runtime/modules/ModuleStress/ExportModuleStressTest.java - assertion failed: address not aligned: 0x00000008baadbabe
Relates :  
JDK-8268523 - SIGSEGV in PackageEntry::purge_qualified_exports()
Description
On behalf of Ekaterina Vergizova <katya@azul.com>:

The attached test crashes on Linux and Windows with OpenJDK 11.0.8 and the latest jdk11u-dev. Full hs_err log is attached.

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007f654f707701, pid=30872, tid=30879
#
# JRE version: OpenJDK Runtime Environment 18.9 (11.0.8+10) (build 11.0.8+10)
# Java VM: OpenJDK 64-Bit Server VM 18.9 (11.0.8+10, mixed mode, tiered, compressed oops, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0xbdf701]  PackageEntry::purge_qualified_exports()+0x131
#
# Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c %d %P %E" (or dumping to /home/cat/work/core.30872)
#
# 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: Test

Host: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz, 4 cores, 7G, Ubuntu 18.04.4 LTS
Time: Mon Aug 17 14:38:38 2020 MSK elapsed time: 29 seconds (0d 0h 0m 29s)

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

Stack: [0x00007f65214fc000,0x00007f65215fc000],  sp=0x00007f65215f9c80,  free space=1015k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0xbdf701]  PackageEntry::purge_qualified_exports()+0x131
V  [libjvm.so+0xbdf79f]  PackageEntryTable::purge_all_package_exports()+0x5f
V  [libjvm.so+0x5b04b2]  ClassLoaderDataGraph::do_unloading(bool)+0x172
V  [libjvm.so+0xd22de5]  SystemDictionary::do_unloading(GCTimer*, bool)+0x45
V  [libjvm.so+0x75644e]  G1ConcurrentMark::remark()+0x8be
V  [libjvm.so+0xdd7e93]  VM_CGC_Operation::doit()+0xc3
V  [libjvm.so+0xdcfa4c]  VM_Operation::evaluate()+0xec
V  [libjvm.so+0xdd5e53]  VMThread::evaluate_operation(VM_Operation*)+0xa3
V  [libjvm.so+0xdd7487]  VMThread::loop()+0x257
V  [libjvm.so+0xdd7a0d]  VMThread::run()+0x6d
V  [libjvm.so+0xd64f2b]  Thread::call_run()+0x6b
V  [libjvm.so+0xbc67b8]  thread_native_entry(Thread*)+0x128
Comments
Fix Request (11u) I would like to fix this bug in openjdk11u. There can be a race when installing class loader data to a java.lang.ClassLoader oop, that can result class loader oop holding stalled class loader data. Although, the race window is quite small, but result can be fatal. 11u patch has been reviewed.
18-06-2021
Here in Modules::add_reads_module, it appears that both oops for modules are good but the ModuleEntry for this one is bad: hsdb> inspect 0x0000000715a57a08 instance of Oop for java/lang/Module @ 0x0000000715a57a08 @ 0x0000000715a57a08 (size = 56) _mark: 245365166337 _metadata._compressed_klass: InstanceKlass for java/lang/Module layer: null null name: null null loader: Oop for Test$PredefinedClassLoader @ 0x0000000715a578a0 Oop for Test$PredefinedClassLoader @ 0x0000000715a578a0 descriptor: null null reads: null null openPackages: null null exportedPackages: null null moduleInfoClass: null null
24-08-2020
When run with -Xlog:module=trace, the test program often crashes here with SIGSEGV: Current thread (0x00007f6fd0833800): JavaThread "pool-1-thread-37" [_thread_in_vm, id=17942, stack(0x00007f6e93dfe000,0x00007f6e93eff000)] Stack: [0x00007f6e93dfe000,0x00007f6e93eff000], sp=0x00007f6e93efcac0, free space=1018k Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x1758166] Symbol::as_C_string() const+0x16 V [libjvm.so+0x13f1910] Modules::add_reads_module(_jobject*, _jobject*, Thread*)+0x250 V [libjvm.so+0xfa9b8e] JVM_AddReadsModule+0xde J 1218 java.lang.Module.addReads0(Ljava/lang/Module;Ljava/lang/Module;)V java.base@11.0.10-internal (0 bytes) @ 0x00007f6fbff660cf [0x00007f6fbff65f60+0x000000000000016f] J 1389 c1 java.lang.Module.implAddReads(Ljava/lang/Module;Z)V java.base@11.0.10-internal (50 bytes) @ 0x00007f6fb8fb9f3c [0x00007f6fb8fb9d00+0x000000000000023c] J 1432 c1 jdk.jfr.internal.SecuritySupport.makeVisibleToJFR(Ljava/lang/Class;)V jdk.jfr@11.0.10-internal (44 bytes) @ 0x00007f6fb8fd5dbc [0x00007f6fb8fd5be0+0x00000000000001dc] ... See hs_err_pid17886.log for details.
21-08-2020
On behalf of Ekaterina Vergizova <katya@azul.com>: The crash is fixed in JDK12 by JDK-8210422, but it requires several prerequisites: JDK-8208677: Move inner metaspace cleaning out of class unloading JDK-8209378: Fix Minimal VM after JDK-8208677 JDK-8207778: Add locking to ModuleEntry and PackageEntry tables JDK-8209821: Make JVMTI GetClassLoaderClasses not walk CLDG JDK-8210155: Lock ClassLoaderDataGraph and missing part of JDK-8213250 related to ClassLoaderDataGraph_lock
18-08-2020