JDK-8223336 : Assert in VirtualMemoryTracker::remove_released_region when running the SharedArchiveConsistency.java test with -XX:NativeMemoryTracking=detail
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 11,13
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows
  • CPU: x86_64
  • Submitted: 2019-05-03
  • Updated: 2019-12-19
  • Resolved: 2019-05-31
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 JDK 13 JDK 14
11.0.5Fixed 13 b24Fixed 14Fixed
Sub Tasks
JDK-8224689 :  
ProblemList runtime/appcds/SharedArchiveConsistency.java - Resolved
Description
#  Internal Error (t:/workspace/open/src/hotspot/share/services/virtualMemoryTracker.cpp:449), pid=7608, tid=316
#  assert(reserved_rgn != 0LL) failed: No reserved region
#
# JRE version:  (13.0) (fastdebug build )
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 13-internal+0-jdk-13-949, mixed mode, aot, sharing, tiered, compressed oops, g1 gc, windows-amd64)

Problem only seen on the Windows platform.

Run the attached test using jtreg as follows:

jtreg -vmoptions: -XX:NativeMemoryTracking=detail SharedArchiveConsistency.java
Comments
Fix Request (11u) I would like to backport this patch to 11u, to avoid test failure on Windows. The whole patch does not apply cleanly, because the failed test is not in 11u's ProblemList.txt, the fix itself applies cleanly.
31-07-2019
With the following change, the crash is no longer reproducible. $ hg diff src/hotspot/os/windows/os_windows.cpp diff --git a/src/hotspot/os/windows/os_windows.cpp b/src/hotspot/os/windows/os_windows.cpp --- a/src/hotspot/os/windows/os_windows.cpp +++ b/src/hotspot/os/windows/os_windows.cpp @@ -4909,6 +4909,7 @@ CloseHandle(hFile); return NULL; } + MemTracker::record_virtual_memory_reserve((address)addr, bytes, CALLER_PC); DWORD bytes_read; OVERLAPPED overlapped;
28-05-2019
The attached test hasn't been checked-in yet. It is part of the dynamic archive changeset. To reproduce the bug, replace the one in the <jdk>/open/test/hotspot/jtreg/runtime/appcds directory with the attached one. Run jtreg with the -vmoptions:-XX:NativeMemoryTracking=detail
03-05-2019
Evaluation from Ioi: From the callstack V [jvm.dll+0xa70f61] os::platform_print_native_stack+0xf1 (os_windows_x86.cpp:369) V [jvm.dll+0xc6f8e1] VMError::report+0xea1 (vmerror.cpp:701) V [jvm.dll+0xc71133] VMError::report_and_die+0x873 (vmerror.cpp:1490) V [jvm.dll+0xc717b4] VMError::report_and_die+0x64 (vmerror.cpp:1288) V [jvm.dll+0x4f0da2] report_vm_error+0x102 (debug.cpp:264) V [jvm.dll+0xc66646] VirtualMemoryTracker::remove_released_region+0xf6 (virtualmemorytracker.cpp:449) V [jvm.dll+0xa61f9a] os::release_memory+0x8a (os.cpp:1764) V [jvm.dll+0xa6d879] os::pd_map_memory+0x139 (os_windows.cpp:4942) <<<<<<< HERE V [jvm.dll+0xa6099a] os::map_memory+0x4a (os.cpp:1776) V [jvm.dll+0x59f341] FileMapInfo::map_regions+0x121 (filemap.cpp:1099) V [jvm.dll+0x9eddb8] MetaspaceShared::initialize_runtime_shared_and_meta_spaces+0xf8 (metaspaceshared.cpp:229) V [jvm.dll+0x9e5122] Metaspace::global_initialize+0x32 (metaspace.cpp:1234) V [jvm.dll+0xc3b011] universe_init+0xb1 (universe.cpp:676) V [jvm.dll+0x698205] init_globals+0x85 (init.cpp:114) V [jvm.dll+0xc10195] Threads::create_vm+0x785 (thread.cpp:3821) V [jvm.dll+0x75a73e] JNI_CreateJavaVM_inner+0xbe (jni.cpp:3933) V [jvm.dll+0x75d57f] JNI_CreateJavaVM+0x1f (jni.cpp:4016) C [jli.dll+0x52ef] JavaMain+0x113 (java.c:414) I think the problem is here around os_windows.cpp:4942 if (!res) { log_info(os)("ReadFile() failed: GetLastError->%ld.", GetLastError()); release_memory(base, bytes); CloseHandle(hFile); return NULL; } it seems to be missing the record_virtual_memory_reserve call (see os_windows.cpp:2900) // NMT has yet to record any individual blocks, so it // need to create a dummy 'reserve' record to match // the release. MemTracker::record_virtual_memory_reserve((address)p_buf, bytes_to_release, CALLER_PC); os::release_memory(p_buf, bytes_to_release);
03-05-2019