JDK-8252921 : NMT overwrite memory type for region assert when building dynamic archive
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 16
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2020-09-08
  • Updated: 2025-01-09
  • Resolved: 2020-09-22
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 16
16 b17Fixed
Related Reports
Relates :  
JDK-8290043 - serviceability/attach/ConcAttachTest.java failed "guarantee(!CheckJNICalls) failed: Attached JNI thread exited without being detached"
Description
runtime/cds/appcds/dynamicArchive/methodHandles/MethodHandlesAsCollectorTest.java
 failed with the following assert/stack trace:

#
#  Internal Error (t:/workspace/open/src/hotspot/share/services/virtualMemoryTracker.cpp:294), pid=33384, tid=3192
#  assert((flag() == mtNone || flag() == f)) failed: Overwrite memory type for region [0x000000a41cf40000-0x000000a41d040000), 3->23.
#

Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [jvm.dll+0xa60a51]  os::platform_print_native_stack+0xf1  (os_windows_x86.cpp:236)
V  [jvm.dll+0xc7ee37]  VMError::report+0xf97  (vmError.cpp:732)
V  [jvm.dll+0xc806ee]  VMError::report_and_die+0x7de  (vmError.cpp:1548)
V  [jvm.dll+0xc80da4]  VMError::report_and_die+0x64  (vmError.cpp:1341)
V  [jvm.dll+0x440ee7]  report_vm_error+0x117  (debug.cpp:264)
V  [jvm.dll+0xc75c06]  ReservedMemoryRegion::set_flag+0x66  (virtualMemoryTracker.cpp:292)
V  [jvm.dll+0xc7433b]  VirtualMemoryTracker::add_reserved_region+0x21b  (virtualMemoryTracker.cpp:353)
V  [jvm.dll+0xa51801]  MemTracker::record_virtual_memory_reserve+0xa1  (memTracker.hpp:219)
V  [jvm.dll+0xa51c39]  os::reserve_memory+0x189  (os.cpp:1673)
V  [jvm.dll+0xc7a8d1]  ReservedSpace::initialize+0x351  (virtualspace.cpp:196)
V  [jvm.dll+0xc79cc6]  ReservedSpace::ReservedSpace+0xa6  (virtualspace.cpp:62)
V  [jvm.dll+0x4bdbf2]  DynamicArchiveBuilder::doit+0x162  (dynamicArchive.cpp:208)
V  [jvm.dll+0x4be42f]  VM_PopulateDynamicDumpSharedSpace::doit+0x5f  (dynamicArchive.cpp:656)
V  [jvm.dll+0xc81fb9]  VM_Operation::evaluate+0xb9  (vmOperations.cpp:68)
V  [jvm.dll+0xc87215]  VMThread::evaluate_operation+0xa5  (vmThread.cpp:359)
V  [jvm.dll+0xc87b50]  VMThread::loop+0x3c0  (vmThread.cpp:484)
V  [jvm.dll+0xc87f6c]  VMThread::run+0xdc  (vmThread.cpp:255)
V  [jvm.dll+0xc10284]  Thread::call_run+0x1b4  (thread.cpp:400)
V  [jvm.dll+0xa5f44e]  thread_native_entry+0x10e  (os_windows.cpp:463)
C  [ucrtbase.DLL+0x1d912]
Comments
This change broke NMT deregistration for attached threads. It broke the normal case where threads attach then detach because detaching doe snot call post_run`. It also broke the cases where attaching failed because now the destructor no longer did the unregister. See JDK-8290043
09-01-2025
Changeset: 8c02bdbf Author: Zhengyu Gu <zgu@openjdk.org> Date: 2020-09-22 11:58:03 +0000 URL: https://git.openjdk.java.net/jdk/commit/8c02bdbf
22-09-2020
Thread stack is currently unregistered with NMT in Thread's destructor. Apparently, only Java thread invokes destructor before thread exits. For NonJavaThread, e.g. ConcurrentGCThread, thread may exit while Thread object continues alive, therefore, its thread stack is still "alive" from NMT perspective.
15-09-2020
The bug reproduces on Windows only so far. Based on my testing, it happened about 1 in 25 runs.
11-09-2020
Attached debug log from windbg on the mini dump - it contains all native threads dump and output of "!analyze -v".
10-09-2020
In both recent failures, nmt is trying to mark a region as 23 (mtNone), but this region was previously marked as 3 (mtThreadStack). From the hs_err file, the region is a thread stack, so it shouldn't be allocated again for the new ReservedSpace. This looks like a bug in NMT. Failure 1: ====== # Internal Error (t:/workspace/open/src/hotspot/share/services/virtualMemoryTracker.cpp:294), pid=15836, tid=21216 # assert((flag() == mtNone || flag() == f)) failed: Overwrite memory type for region [0x00000072d85e0000-0x00000072d86e0000), 3->23. 0x00000072d83e7be0 ConcurrentGCThread "G1 Main Marker" [stack: 0x00000072d85e0000,0x00000072d86e0000] [id=38484] Failure 2: ====== # Internal Error (t:/workspace/open/src/hotspot/share/services/virtualMemoryTracker.cpp:294), pid=33384, tid=3192 # assert((flag() == mtNone || flag() == f)) failed: Overwrite memory type for region [0x000000a41cf40000-0x000000a41d040000), 3->23. 0x000000a47fdee080 ConcurrentGCThread "G1 Main Marker" [stack: 0x000000a41cf40000,0x000000a41d040000] [id=17068]
09-09-2020
These changes change the sizing of eden, i.e. how many (already committed) regions are allocated to it. It changes the frequency and interval. This is far removed from any CDS activity. Also occurred once in another mach5 run in the same test by somebody else.
09-09-2020
Thomas, I don't see how CDS can cause this issue. The code simply calls the ReservedSpace(size_t) constructor. address DynamicArchiveBuilder::reserve_space_and_init_buffer_to_target_delta() { size_t total = estimate_archive_size(); ReservedSpace rs(total); <<<<<<<<< HERE if (!rs.is_reserved()) { log_error(cds, dynamic)("Failed to reserve %d bytes of output buffer.", (int)total); vm_direct_exit(0); } Could you check if this might be caused by your pending changes in JDK-8249676?
09-09-2020
ILW=HLM=P3
08-09-2020