Bug ID: JDK-8222379 JFR TestClassLoadEvent.java failed due to EXCEPTION_ACCESS

Type: Bug
Component: hotspot
Sub-Component: runtime
Affected Version: 13

Priority: P2
Status: Closed
Resolution: Fixed
OS: windows
CPU: x86_64

Submitted: 2019-04-12
Updated: 2024-02-16
Resolved: 2019-04-18

JDK 13
13 b18Fixed

The following test failed in the jdk/jdk CI:

jdk/jfr/event/runtime/TestClassLoadEvent.java

Here's a snippet of the log file:

----------System.out:(23/1141)*----------
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffa1dbb32ab, pid=88496, tid=135856
#
# JRE version: Java(TM) SE Runtime Environment (13.0) (build 13-internal+0-jdk13-jdk.822)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (13-internal+0-jdk13-jdk.822, mixed mode, tiered, compressed oops, g1 gc, windows-amd64)
# Problematic frame:
# [2.372s][error][jfr,system] JfrJvmtiAgent::retransformClasses failed
V  [jvm.dll+0x1e32ab][thread 82388 also had an error]
  CodeBuffer::finalize_oop_references+0x17b
#
# Core dump will be written. Default location: T:\\testoutput\\test-support\\jtreg_open_test_jdk_tier1_part3\\scratch\\2\\hs_err_pid88496.mdmp
#
# An error report file with more information is saved as:
# T:\\testoutput\\test-support\\jtreg_open_test_jdk_tier1_part3\\scratch\\2\\hs_err_pid88496.log

[error occurred during error reporting (), id 0xc0000005, EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffa1e08fc94]

#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
#
----------System.err:(0/0)----------

Since this is a tier1 failures, I've set the initial priority to P2.

URL: http://hg.openjdk.java.net/jdk/jdk/rev/b73893f7fee3 User: coleenp Date: 2019-04-18 11:36:54 +0000
18-04-2019
This test apparently ran into this: // Remap a block of memory. char* os::pd_remap_memory(int fd, const char* file_name, size_t file_offset, char *addr, size_t bytes, bool read_only, bool allow_exec) { // This OS does not allow existing memory maps to be remapped so we // have to unmap the memory before we remap it. if (!os::unmap_memory(addr, bytes)) { return NULL; } // There is a very small theoretical window between the unmap_memory() // call above and the map_memory() call below where a thread in native // code may be able to access an address that is no longer mapped. return os::map_memory(fd, file_name, file_offset, addr, bytes, read_only, allow_exec); } [~iklam] Should we hard fail or should we retry a couple times before hard failing? What do you think?
15-04-2019
This is a CDS/RedefineClasses bug. Reassigning it to runtime. UseSharedSpaces == true here #if INCLUDE_CDS if (UseSharedSpaces) { // Sharing is enabled so we remap the shared readonly space to // shared readwrite, private just in case we need to redefine // a shared class. We do the remap during the doit() phase of // the safepoint to be safer. if (!MetaspaceShared::remap_shared_readonly_as_readwrite()) { log_info(redefine, class, load)("failed to remap shared readonly space to readwrite, private"); _res = JVMTI_ERROR_INTERNAL; return; } } #endif still true: bool MetaspaceShared::remap_shared_readonly_as_readwrite() { assert(SafepointSynchronize::is_at_safepoint(), "must be at safepoint"); if (UseSharedSpaces) { // remap the shared readonly space to shared readwrite, private FileMapInfo* mapinfo = FileMapInfo::current_info(); if (!mapinfo->remap_shared_readonly_as_readwrite()) { return false; } _remapped_readwrite = true; } return true; } bool FileMapInfo::remap_shared_readonly_as_readwrite() { ... fail_continue(...) ... void FileMapInfo::fail_continue(const char *msg, ...) { ... UseSharedSpaces = false; Looks like we failed to remap the shared spaces then set UseSharedSpaces to false. I don't know if we unnmapped the archive when we did this, or if the metaspace boundaries are now incorrect. Edit: yes, it looks like if we get this error, we've unmapped the memory. We need to give a fatal error message before we crash.
12-04-2019
Hard coding the remap_shared_readonly_as_rewrite to fail and call fail_continue doesn't give this crash on linux in product mode. TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.ClassFormatError: JfrJvmtiAgent::retransformClasses failed -------------------------------------------------- Test results: failed: 1
12-04-2019
Here's the crashing thread's call stack: --------------- T H R E A D --------------- Current thread (0x0000000879f07000): JavaThread "C1 CompilerThread0" daemon [_thread_in_vm, id=135856, stack(0x000000087a8f0000,0x000000087a9f0000)] Current CompileTask: C1: 2517 969 3 [error occurred during error reporting (printing current compile task), id 0xc0000005, EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffa1df805f4] Stack: [0x000000087a8f0000,0x000000087a9f0000], sp=0x000000087a9eeb30, free space=1018k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [jvm.dll+0x1e32ab] CodeBuffer::finalize_oop_references+0x17b (codebuffer.cpp:564) V [jvm.dll+0x5d31ee] nmethod::new_nmethod+0xfe (nmethod.cpp:495) V [jvm.dll+0x1a4668] ciEnv::register_method+0x458 (cienv.cpp:1047) V [jvm.dll+0x126b6d] Compilation::compile_method+0x27d (c1_compilation.cpp:470) V [jvm.dll+0x125d27] Compilation::Compilation+0x1a7 (c1_compilation.cpp:584) V [jvm.dll+0x127c47] Compiler::compile_method+0x87 (c1_compiler.cpp:248) V [jvm.dll+0x211a44] CompileBroker::invoke_compiler_on_method+0x704 (compilebroker.cpp:2123) V [jvm.dll+0x20ff8d] CompileBroker::compiler_thread_loop+0x23d (compilebroker.cpp:1804) V [jvm.dll+0x7067b6] JavaThread::run+0x136 (thread.cpp:1862) V [jvm.dll+0x6ff93a] Thread::call_run+0x8a (thread.cpp:410) V [jvm.dll+0x5f5726] thread_native_entry+0xd6 (os_windows.cpp:471) C [ucrtbase.DLL+0x203ba] C [KERNEL32.DLL+0x13d2] C [ntdll.dll+0x154f4] I'm attaching the hs_err_pid file.
12-04-2019