JDK-8340401 : DcmdMBeanPermissionsTest.java and SystemDumpMapTest.java fail with assert(_stack_base != nullptr) failed: Sanity check
  • Type: Bug
  • Component: core-svc
  • Sub-Component: tools
  • Affected Version: 24
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows
  • CPU: x86_64
  • Submitted: 2024-09-18
  • Updated: 2024-12-25
  • Resolved: 2024-12-19
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 25
25 b03Fixed
Related Reports
Relates :  
JDK-8340491 - Thread stack-base assertion should report which thread has the un-set stack
Relates :  
JDK-8346717 - serviceability/dcmd/vm/SystemDumpMapTest.java failing on Windows with "Stack base not yet set for thread id"
Relates :  
JDK-8342482 - Use the same native thread initialization procedure on all platforms
Relates :  
JDK-8319873 - Add windows implementation for jcmd System.map and System.dump_map
Sub Tasks
JDK-8340540 :  
Problemlist DcmdMBeanPermissionsTest.java and SystemDumpMapTest.java - Resolved
Description
The following test failed in the JDK24 CI:

com/sun/management/DiagnosticCommandMBean/DcmdMBeanPermissionsTest.java

Here's a snippet from the log file:

#section:main
----------messages:(7/400)----------
command: main -Djava.security.manager=allow DcmdMBeanPermissionsTest
reason: User specified action: run main/othervm -Djava.security.manager=allow DcmdMBeanPermissionsTest 
started: Wed Sep 18 16:20:51 UTC 2024
Mode: othervm [/othervm specified]
Additional options from @modules: --add-modules java.logging,java.management
finished: Wed Sep 18 16:21:06 UTC 2024
elapsed time (seconds): 14.671
----------configuration:(3/59)----------
Boot Layer
  add modules: java.logging java.management

----------System.out:(41/1593)*----------
Testing compilerCodeHeapAnalytics
Testing compilerCodecache
Testing compilerCodelist
Testing compilerDirectivesAdd
Testing compilerDirectivesClear
Testing compilerDirectivesPrint
Testing compilerDirectivesRemove
Testing compilerMemory
Testing compilerQueue
Testing gcClassHistogram
Testing gcFinalizerInfo
Testing gcHeapInfo
Testing gcRun
Testing gcRunFinalization
Testing help
Testing jfrCheck
Testing jfrConfigure
Testing jfrDump
Testing jfrStart
Testing jfrStop
Testing jfrView
Testing jvmtiAgentLoad
Testing jvmtiDataDump
Testing systemDumpMap
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (c:\\sb\\prod\\1726663901\\workspace\\open\\src\\hotspot\\share\\runtime/thread.hpp:535), pid=44680, tid=20508
#  assert(_stack_base != nullptr) failed: Sanity check
#
# JRE version: Java(TM) SE Runtime Environment (24.0+16) (fastdebug build 24-ea+16-1777)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 24-ea+16-1777, mixed mode, sharing, tiered, compressed class ptrs, z gc, windows-amd64)
# Core dump will be written. Default location: C:\\sb\\prod\\1726676244\\testoutput\\test-support\\jtreg_open_test_jdk_jdk_management\\scratch\\0\\hs_err_pid44680.mdmp
#
# An error report file with more information is saved as:
# C:\\sb\\prod\\1726676244\\testoutput\\test-support\\jtreg_open_test_jdk_jdk_management\\scratch\\0\\hs_err_pid44680.log
[4.628s][warning][os] Loading hsdis library failed
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp
#
----------System.err:(6/712)----------
Java HotSpot(TM) 64-Bit Server VM warning: Option ZGenerational was deprecated in version 23.0 and will likely be removed in a future release.
Java HotSpot(TM) 64-Bit Server VM warning: Non-generational ZGC is deprecated.
WARNING: A terminally deprecated method in java.lang.System has been called
WARNING: System::setSecurityManager has been called by DcmdMBeanPermissionsTest (file:/C:/sb/prod/1726676244/testoutput/test-support/jtreg_open_test_jdk_jdk_management/classes/1/com/sun/management/DiagnosticCommandMBean/DcmdMBeanPermissionsTest.d/)
WARNING: Please consider reporting this to the maintainers of DcmdMBeanPermissionsTest
WARNING: System::setSecurityManager will be removed in a future release
----------rerun:(47/6059)*----------

Here's the crashing thread's stack:

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

Current thread (0x00000273c16ad670):  JavaThread "MainThread"        [_thread_in_vm, id=20508, stack(0x000000de1e300000,0x000000de1e400000) (1024K)] _threads_hazard_ptr=0x00000273c1441b40, _nested_threads_hazard_ptr_cnt=0

Stack: [0x000000de1e300000,0x000000de1e400000]
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [jvm.dll+0xce9d41]  os::win32::platform_print_native_stack+0x101  (os_windows_x86.cpp:235)
V  [jvm.dll+0xfaeeeb]  VMError::report+0x149b  (vmError.cpp:1011)
V  [jvm.dll+0xfb158d]  VMError::report_and_die+0x80d  (vmError.cpp:1846)
V  [jvm.dll+0xfb1c84]  VMError::report_and_die+0x64  (vmError.cpp:1611)
V  [jvm.dll+0x57dccb]  report_vm_error+0x5b  (debug.cpp:193)
V  [jvm.dll+0xc08f66]  vma_touches_thread_stack+0x86  (memMapPrinter.cpp:175)
V  [jvm.dll+0xc08cdb]  print_thread_details_for_supposed_stack_address+0x8b  (memMapPrinter.cpp:217)
V  [jvm.dll+0xc08ac4]  MappingPrintSession::print_nmt_info_for_region+0x1f4  (memMapPrinter.cpp:260)
V  [jvm.dll+0xc09540]  MemMapPrinter::pd_print_all_mappings+0x4c0  (memMapPrinter_windows.cpp:244)
V  [jvm.dll+0xc086ce]  MemMapPrinter::print_all_mappings+0x7e  (memMapPrinter.cpp:282)
V  [jvm.dll+0x60cbe7]  SystemDumpMapDCmd::execute+0x67  (diagnosticCommand.cpp:1211)
V  [jvm.dll+0x60ffe5]  DCmd::parse_and_execute+0x505  (diagnosticFramework.cpp:416)
V  [jvm.dll+0xbed5ad]  jmm_ExecuteDiagnosticCommand+0x15d  (management.cpp:2082)
C  0x00000273dee17055  (no source info available)

The last pc belongs to native nmethod (printed below).
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
J 1009  com.sun.management.internal.DiagnosticCommandImpl.executeDiagnosticCommand(Ljava/lang/String;)Ljava/lang/String; jdk.management@24-ea (0 bytes) @ 0x00000273dee1701c [0x00000273dee16fa0+0x000000000000007c]
j  com.sun.management.internal.DiagnosticCommandImpl$Wrapper.execute([Ljava/lang/String;)Ljava/lang/String;+35 jdk.management@24-ea
j  com.sun.management.internal.DiagnosticCommandImpl.invoke(Ljava/lang/String;[Ljava/lang/Object;[Ljava/lang/String;)Ljava/lang/Object;+134 jdk.management@24-ea
j  com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(Ljavax/management/ObjectName;Ljava/lang/String;[Ljava/lang/Object;[Ljava/lang/String;)Ljava/lang/Object;+29 java.management@24-ea
j  com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(Ljavax/management/ObjectName;Ljava/lang/String;[Ljava/lang/Object;[Ljava/lang/String;)Ljava/lang/Object;+13 java.management@24-ea
j  DcmdMBeanPermissionsTest.invokeOperation(Ljavax/management/MBeanServer;Ljavax/management/ObjectName;Ljavax/management/MBeanOperationInfo;)Z+53
j  DcmdMBeanPermissionsTest.testOperation(Ljavax/management/MBeanServer;LDcmdMBeanPermissionsTest$CustomSecurityManager;Ljavax/management/ObjectName;Ljavax/management/MBeanOperationInfo;)V+127
j  DcmdMBeanPermissionsTest.main([Ljava/lang/String;)V+241
j  java.lang.invoke.LambdaForm$DMH+0x00000273c24083e0.invokeStatic(Ljava/lang/Object;Ljava/lang/Object;)V+10 java.base@24-ea
j  java.lang.invoke.LambdaForm$MH+0x00000273c240ac10.invoke(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;+33 java.base@24-ea
j  java.lang.invoke.Invokers$Holder.invokeExact_MT(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;+20 java.base@24-ea
j  jdk.internal.reflect.DirectMethodHandleAccessor.invokeImpl(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+55 java.base@24-ea
j  jdk.internal.reflect.DirectMethodHandleAccessor.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+23 java.base@24-ea
j  java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+102 java.base@24-ea
j  com.sun.javatest.regtest.agent.MainWrapper$MainTask.run()V+134
j  java.lang.Thread.runWith(Ljava/lang/Object;Ljava/lang/Runnable;)V+5 java.base@24-ea
j  java.lang.Thread.run()V+19 java.base@24-ea
v  ~StubRoutines::call_stub 0x00000273de83104f
Lock stack of current Java thread (top to bottom):


Compiled method (n/a) 4627 1009     n 0       com.sun.management.internal.DiagnosticCommandImpl::executeDiagnosticCommand (native)
 total in heap  [0x00000273dee16e88,0x00000273dee17300] = 1144
 relocation     [0x00000273dee16f70,0x00000273dee16f90] = 32
 main code      [0x00000273dee16fa0,0x00000273dee172ff] = 863
 stub code      [0x00000273dee172ff,0x00000273dee17300] = 1

Since the crash appears to be happening in the DCmd implementation
I'm starting this bug off in core-svc/tools for initial triage.
Comments
Changeset: b0c40aad Branch: master Author: Simon Tooke <stooke@openjdk.org> Date: 2024-12-19 02:12:02 +0000 URL: https://git.openjdk.org/jdk/commit/b0c40aadd2f028cf43eebdd2070411bb4a9bd09e
19-12-2024
These tests are problemlisted for windows-all in jdk-24+17-1842
20-09-2024
[~dholmes] spot on. A We create thread in suspended state B parent calls "JavaThread::prepare_thread", which adds thread to global thread list C parent starts thread D child thread sets stack boundaries Between B and D thread is observable in list but has no stack.
20-09-2024
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/21091 Date: 2024-09-19 14:51:01 +0000
20-09-2024
This is a problem caused by a difference in the thread startup logic on Windows. On Windows we can actually create the native thread in the suspended state, and then os::start_thread resumes it. Once it starts running the first thing it does is `record_stack_size_and_base`. But os::start_thread is called after Threads::add which makes the new thread visible to the JavaThread iterators as used in this code. So we can clearly have the iterator encounter a new thread that has not yet had a chance to set its stack size and base. This problem cannot happen on non-Windows because on those platforms we implement a manual "suspend/resume" mechanism for new threads whereby os::create_thread starts the native thread then waits for it to signal that it is initialized. The native thread itself will first do `record_stack_size_and_base` and some other initialization, and then signal the creator thread that it is initialized, and then proceeds to wait until os::start_thread "resumes" it. Consequently, on non-Windows, the new thread is guaranteed to have an initialized stack before it becomes visible to the JavaThread iterator. So really any code that uses a JavaThread iterator needs to be aware of the fact it can run into such a thread and allow for that. In this case the proposed check of the stack_size for 0 will suffice, though I think it would be better placed directly in the iterating code than in the vma_touches_thread_stack function.
20-09-2024
With the augmented assert I was able to reproduce this in our tier 5 CI testing: # assert(_stack_base != nullptr) failed: Stack base not yet set for thread id:20988 (0 if not set) and: 0x000001e1c73da7a0 JavaThread "ForkJoinPool-1-worker-3" daemon [_thread_blocked, id=20988, stack(0x000000d944d00000,0x000000d944e00000) (1024K)]
20-09-2024
The failing assertion is written assuming it pertains to the current thread, which is not the case here: // Given a region [from, to), if it intersects a known thread stack, print detail infos about that thread. static void print_thread_details_for_supposed_stack_address(const void* from, const void* to, outputStream* st) { ResourceMark rm; #define HANDLE_THREAD(T) \ if (T != nullptr && vma_touches_thread_stack(from, to, T)) { \ print_thread_details((uintx)(T->osthread()->thread_id()), T->name(), st); \ return; \ } for (JavaThreadIteratorWithHandle jtiwh; JavaThread* t = jtiwh.next(); ) { HANDLE_THREAD(t); } HANDLE_THREAD(VMThread::vm_thread()); HANDLE_THREAD(WatcherThread::watcher_thread()); HANDLE_THREAD(AsyncLogWriter::instance()); #undef HANDLE_THREAD // Given a VMA [from, to) and a thread, check if vma intersects with thread stack static bool vma_touches_thread_stack(const void* from, const void* to, const Thread* t) { // Java thread stacks (and sometimes also other threads) have guard pages. Therefore they typically occupy // at least two distinct neighboring VMAs. Therefore we typically have a 1:n relationshipt between thread // stack and vma. // Very rarely however is a VMA backing a thread stack folded together with another adjacent VMA by the // kernel. That can happen, e.g., for non-java threads that don't have guard pages. // Therefore we go for the simplest way here and check for intersection between VMA and thread stack. return range_intersects(from, to, (const void*)t->stack_end(), (const void*)t->stack_base()); } So it would be useful to actually report which thread had the bad stack - JDK-8340491
19-09-2024
I'm unclear what the GC threads have to do with this as they are not Java threads and will not be iterated.
19-09-2024
Thanks [~dcubed] yes I have done some testing of the small fix [~stooke] suggested to avoid the problem, and cannot get a problem in various testing tier 1,2,3. He should pull that out of draft when he's online and go for it. 8-)
19-09-2024
This bug feels like a regression introduced by the following fix: JDK-8319873 Add windows implementation for jcmd System.map and System.dump_map so normally I would bump the priority from P3 -> P2 and add the regression label. However, it seems that what JDK-8319873 did was allow both of these tests: serviceability/dcmd/vm/SystemMapTest.java serviceability/dcmd/vm/SystemDumpMapTest.java to execute on windows. Another reason to bump this from P3 -> P2 is that it is rather noisy in CI, but there's a lot of activity on the bug so I don't think any cages need to be rattled here. Other opinions are welcome here...
19-09-2024
It seems fairly common on Windows for a JavaThread with no stack_base or stack_size to be visible via the JavaThreadIteratorWithHandle iterator. At least, common in that I see this during the build process, but can't trigger it on demand. e.g. ... Creating jdk.management.jfr.jmod XXXXX JavaThread stack_size==0 000002454F388E30 'C1 CompilerThread3' XXXXX JavaThread stack_size==0 000002454F388E30 'C1 CompilerThread3' Creating jdk.naming.dns.jmod ... XXXXX JavaThread stack_size==0 0000024BD9CA3B80 'C2 CompilerThread3' XXXXX JavaThread stack_size==0 0000024BDB2953F0 'C2 CompilerThread5' XXXXX JavaThread stack_size==0 000002361947AC60 'Finalizer' XXXXX JavaThread stack_size==0 000002361947AC60 'Finalizer' XXXXX JavaThread stack_size==0 000002361947AC60 'Finalizer' XXXXX JavaThread stack_size==0 00000236194D2E40 'C1 CompilerThread0' ... XXXXX JavaThread stack_size==0 00000236194D2E40 'C1 CompilerThread0' XXXXX JavaThread stack_size==0 0000023619D4C380 'ForkJoinPool.commonPool-worker-1' XXXXX JavaThread stack_size==0 0000023619D4EB10 'ForkJoinPool.commonPool-worker-2' XXXXX JavaThread stack_size==0 00000202373141C0 'Common-Cleaner' XXXXX JavaThread stack_size==0 00000202373141C0 'Common-Cleaner'
19-09-2024
Just luck perhaps on reproducing it right now. ZGC is commonly present but I see one, noted above, without it (maybe more by now...). Tried more concurrent gc worker threads, can't provoke the problem locally. Yes the stack_size() check might be good, as that's also set in Thread::record_stack_base_and_size() which happens in thread_native_entry(void* t) (and we don't assert if you read it and find a zero!). David's note above suggests we might have a general problem of threads being visible through the iterator when they aren't ready. Seems that we do.. But yes the size check might be good as a quick fix, this is quite noisy. I will test it also.
19-09-2024
I am unable to duplicate this yet, but walked through the code. How might I duplicate the error? I am trying to force ZGC but the failure might be machine-dependent. I have a draft PR I'm preparing, with a simple check for a 0-length thread stack. https://github.com/openjdk/jdk/pull/21091
19-09-2024
So far it's always GC worker threads that are part of the problem. Not ZGC specific, e.g. 0x00000273cebc9200 WorkerThread "XWorker#0" [id=45968, stack(0x000000de1c800000,0x000000de1c900000) (1024K)] 0x00000155c3497ec0 ConcurrentGCThread "ZUnmapper" [id=30292, stack(0x0000004333b00000,0x0000004333c00000) (1024K)] 0x000002226936d2a0 ConcurrentGCThread "ZUnmapper" [id=47100, stack(0x0000009a86400000,0x0000009a86500000) (1024K)] and also G1, NOT ZGC: 0x00000256915b5160 WorkerThread "GC Thread#0" [id=120972, stack(0x0000009ed9400000,0x0000009ed9500000) (1024K)] They have stack info in the thread list in hs_err... But yes that's later after we have faulted and are printing hs_err... JavaThreadIteratorWithHandle could check it's not publishing incomplete threads... Trying a quick check like: $ git diff diff --git a/src/hotspot/share/runtime/threadSMR.hpp b/src/hotspot/share/runtime/threadSMR.hpp index a379e820587..bfd53bd2b50 100644 --- a/src/hotspot/share/runtime/threadSMR.hpp +++ b/src/hotspot/share/runtime/threadSMR.hpp @@ -417,7 +417,9 @@ class JavaThreadIteratorWithHandle : public StackObj { if (_index >= length()) { return nullptr; } - return _tlh.list()->thread_at(_index++); + JavaThread* jt = _tlh.list()->thread_at(_index++); + jt->stack_base(); + return jt; } On Linux this builds and runs OK. On Windows, it crashes during build. V [jvm.dll+0x57dd7b] report_vm_error+0x5b (debug.cpp:193) V [jvm.dll+0x776b60] GlobalCounter::write_synchronize+0x220 (globalCounter.cpp:67) V [jvm.dll+0x67da54] FreeListAllocator::release+0x124 (freeListAllocator.cpp:158) V [jvm.dll+0x69ae66] G1CardSet::add_to_howl+0x286 (g1CardSet.cpp:583) ...etc... GlobalCounter::write_synchronize uses JavaThreadIteratorWithHandle and asserts reliably.
19-09-2024
The code is iterating all threads. We need to check that a newly created thread that has not yet had a chance to run and set its own stack base, is not visible via the iterator.
19-09-2024
Crashes are within a few seconds of startup. Assert says some thread stack has a nullptr stack base. vm_memory_map_44680.txt stops at: ... 0x000000de1c6fd000-0x000000de1c700000 12288 rw- c-pvt 0xfd000 0x000000de1c700000-0x000000de1c704000 16384 rw-g c-pvt 0 STACK-45408-main 0x000000de1c704000-0x000000de1c7ea000 942080 --- r-pvt 0x4000 STACK-45408-main 0x000000de1c7ea000-0x000000de1c7ed000 12288 rw-g c-pvt 0xea000 STACK-45408-main 0x000000de1c7ed000-0x000000de1c800000 77824 rw- c-pvt 0xed000 STACK-45408-main 0x000000de1c800000-0x000000de1c8f6000 1007616 --- r-pvt 0 STACK ..and stack address 0xde1c800000 is: 0x00000273cebc9200 WorkerThread "XWorker#0" [id=45968, stack(0x000000de1c800000,0x000000de1c900000) (1024K)]
19-09-2024
This bug documents that DcmdMBeanPermissionsTest.java fails assert(_stack_base != nullptr) AND serviceability/dcmd/vm/SystemDumpMapTest.java fails the same way: SystemDumpMapTest failure: ----------System.out:(18/1127)*---------- Running DCMD 'System.dump_map -F=test-map.txt' through 'JMXExecutor' # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (.....\workspace\\open\\src\\hotspot\\share\\runtime/thread.hpp:535), pid=20612, tid=17252 # assert(_stack_base != nullptr) failed: Sanity check # # JRE version: Java(TM) SE Runtime Environment (24.0+16) (fastdebug build 24-ea+16-1791) # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 24-ea+16-1791, mixed mode, sharing, tiered, compressed class ptrs, z gc, windows-amd64) hs_err: Current thread (0x000001bb7e297d40): JavaThread "MainThread" [_thread_in_vm, id=17252, stack(0x000000a515400000,0x000000a515500000) (1024K)] _threads_hazard_ptr=0x000001bb7ee0dd30, _nested_threads_hazard_ptr_cnt=0 Stack: [0x000000a515400000,0x000000a515500000] Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [jvm.dll+0xce9d41] os::win32::platform_print_native_stack+0x101 (os_windows_x86.cpp:235) V [jvm.dll+0xfaeeeb] VMError::report+0x149b (vmError.cpp:1011) V [jvm.dll+0xfb158d] VMError::report_and_die+0x80d (vmError.cpp:1846) V [jvm.dll+0xfb1c84] VMError::report_and_die+0x64 (vmError.cpp:1611) V [jvm.dll+0x57dccb] report_vm_error+0x5b (debug.cpp:193) V [jvm.dll+0xc08f66] vma_touches_thread_stack+0x86 (memMapPrinter.cpp:175) V [jvm.dll+0xc08cdb] print_thread_details_for_supposed_stack_address+0x8b (memMapPrinter.cpp:217) V [jvm.dll+0xc08ac4] MappingPrintSession::print_nmt_info_for_region+0x1f4 (memMapPrinter.cpp:260) V [jvm.dll+0xc09540] MemMapPrinter::pd_print_all_mappings+0x4c0 (memMapPrinter_windows.cpp:244) V [jvm.dll+0xc086ce] MemMapPrinter::print_all_mappings+0x7e (memMapPrinter.cpp:282) V [jvm.dll+0x60cbe7] SystemDumpMapDCmd::execute+0x67 (diagnosticCommand.cpp:1211) V [jvm.dll+0x60ffe5] DCmd::parse_and_execute+0x505 (diagnosticFramework.cpp:416) V [jvm.dll+0xbed5ad] jmm_ExecuteDiagnosticCommand+0x15d (management.cpp:2082) C 0x000001b72d9ae77e (no source info available) where the created file test-map.txt stops abruptly: from to vsize prot state offset vminfo/file =========================================================================================== 0x000000007ffe0000-0x000000007ffe1000 4096 r-- c-pvt 0 0x000000a512e00000-0x000000a512e0a000 40960 rw- c-pvt 0 0x000000a512e0a000-0x000000a512fbb000 1773568 --- r-pvt 0xa000 0x000000a512fbb000-0x000000a513000000 282624 rw- c-pvt 0x1bb000 0x000000a513000000-0x000000a5130f9000 1019904 --- r-pvt 0 0x000000a5130f9000-0x000000a5130fc000 12288 rw-g c-pvt 0xf9000 0x000000a5130fc000-0x000000a513100000 16384 rw- c-pvt 0xfc000 0x000000a513100000-0x000000a5131fa000 1024000 --- r-pvt 0 0x000000a5131fa000-0x000000a5131fd000 12288 rw-g c-pvt 0xfa000 0x000000a5131fd000-0x000000a513200000 12288 rw- c-pvt 0xfd000 0x000000a513200000-0x000000a5132fb000 1028096 --- r-pvt 0 0x000000a5132fb000-0x000000a5132fe000 12288 rw-g c-pvt 0xfb000 0x000000a5132fe000-0x000000a513300000 8192 rw- c-pvt 0xfe000 0x000000a513300000-0x000000a513304000 16384 rw-g c-pvt 0 STACK-4124-main 0x000000a513304000-0x000000a5133ea000 942080 --- r-pvt 0x4000 STACK-4124-main 0x000000a5133ea000-0x000000a5133ed000 12288 rw-g c-pvt 0xea000 STACK-4124-main 0x000000a5133ed000-0x000000a513400000 77824 rw- c-pvt 0xed000 STACK-4124-main 0x000000a513400000-0x000000a5134fb000 1028096 --- r-pvt 0 STACK A DcmdMBeanPermissionsTest.java failure: Current thread (0x00000273c16ad670): JavaThread "MainThread" [_thread_in_vm, id=20508, stack(0x000000de1e300000,0x000000de1e400000) (1024K)] _threads_hazard_ptr=0x00000273c1441b40, _nested_threads_hazard_ptr_cnt=0 Stack: [0x000000de1e300000,0x000000de1e400000] Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [jvm.dll+0xce9d41] os::win32::platform_print_native_stack+0x101 (os_windows_x86.cpp:235) V [jvm.dll+0xfaeeeb] VMError::report+0x149b (vmError.cpp:1011) V [jvm.dll+0xfb158d] VMError::report_and_die+0x80d (vmError.cpp:1846) V [jvm.dll+0xfb1c84] VMError::report_and_die+0x64 (vmError.cpp:1611) V [jvm.dll+0x57dccb] report_vm_error+0x5b (debug.cpp:193) V [jvm.dll+0xc08f66] vma_touches_thread_stack+0x86 (memMapPrinter.cpp:175) V [jvm.dll+0xc08cdb] print_thread_details_for_supposed_stack_address+0x8b (memMapPrinter.cpp:217) V [jvm.dll+0xc08ac4] MappingPrintSession::print_nmt_info_for_region+0x1f4 (memMapPrinter.cpp:260) V [jvm.dll+0xc09540] MemMapPrinter::pd_print_all_mappings+0x4c0 (memMapPrinter_windows.cpp:244) V [jvm.dll+0xc086ce] MemMapPrinter::print_all_mappings+0x7e (memMapPrinter.cpp:282) V [jvm.dll+0x60cbe7] SystemDumpMapDCmd::execute+0x67 (diagnosticCommand.cpp:1211) V [jvm.dll+0x60ffe5] DCmd::parse_and_execute+0x505 (diagnosticFramework.cpp:416) V [jvm.dll+0xbed5ad] jmm_ExecuteDiagnosticCommand+0x15d (management.cpp:2082) C 0x00000273dee17055 (no source info available) Created file vm_memory_map_44680.txt also stops sharp: from to vsize prot state offset vminfo/file =========================================================================================== 0x000000007ffe0000-0x000000007ffe1000 4096 r-- c-pvt 0 0x000000de1c020000-0x000000de1c119000 1019904 --- r-pvt 0 0x000000de1c119000-0x000000de1c11c000 12288 rw-g c-pvt 0xf9000 0x000000de1c11c000-0x000000de1c120000 16384 rw- c-pvt 0xfc000 0x000000de1c200000-0x000000de1c23e000 253952 rw- c-pvt 0 0x000000de1c23e000-0x000000de1c246000 32768 --- r-pvt 0x3e000 0x000000de1c246000-0x000000de1c248000 8192 rw- c-pvt 0x46000 0x000000de1c248000-0x000000de1c3fb000 1781760 --- r-pvt 0x48000 0x000000de1c3fb000-0x000000de1c400000 20480 rw- c-pvt 0x1fb000 0x000000de1c400000-0x000000de1c4f9000 1019904 --- r-pvt 0 0x000000de1c4f9000-0x000000de1c4fc000 12288 rw-g c-pvt 0xf9000 0x000000de1c4fc000-0x000000de1c500000 16384 rw- c-pvt 0xfc000 0x000000de1c500000-0x000000de1c5fb000 1028096 --- r-pvt 0 0x000000de1c5fb000-0x000000de1c5fe000 12288 rw-g c-pvt 0xfb000 0x000000de1c5fe000-0x000000de1c600000 8192 rw- c-pvt 0xfe000 0x000000de1c600000-0x000000de1c6fa000 1024000 --- r-pvt 0 0x000000de1c6fa000-0x000000de1c6fd000 12288 rw-g c-pvt 0xfa000 0x000000de1c6fd000-0x000000de1c700000 12288 rw- c-pvt 0xfd000 0x000000de1c700000-0x000000de1c704000 16384 rw-g c-pvt 0 STACK-45408-main 0x000000de1c704000-0x000000de1c7ea000 942080 --- r-pvt 0x4000 STACK-45408-main 0x000000de1c7ea000-0x000000de1c7ed000 12288 rw-g c-pvt 0xea000 STACK-45408-main 0x000000de1c7ed000-0x000000de1c800000 77824 rw- c-pvt 0xed000 STACK-45408-main 0x000000de1c800000-0x000000de1c8f6000 1007616 --- r-pvt 0 STACK
19-09-2024
These commands are newly run on Windows after JDK-8319873
19-09-2024
Also test: serviceability/dcmd/vm/SystemDumpMapTest.java --------------- T H R E A D --------------- Current thread (0x000001bb7e297d40): JavaThread "MainThread" [_thread_in_vm, id=17252, stack(0x000000a515400000,0x000000a515500000) (1024K)] _threads_hazard_ptr=0x000001bb7ee0dd30, _nested_threads_hazard_ptr_cnt=0 Stack: [0x000000a515400000,0x000000a515500000] Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [jvm.dll+0xce9d41] os::win32::platform_print_native_stack+0x101 (os_windows_x86.cpp:235) V [jvm.dll+0xfaeeeb] VMError::report+0x149b (vmError.cpp:1011) V [jvm.dll+0xfb158d] VMError::report_and_die+0x80d (vmError.cpp:1846) V [jvm.dll+0xfb1c84] VMError::report_and_die+0x64 (vmError.cpp:1611) V [jvm.dll+0x57dccb] report_vm_error+0x5b (debug.cpp:193) V [jvm.dll+0xc08f66] vma_touches_thread_stack+0x86 (memMapPrinter.cpp:175) V [jvm.dll+0xc08cdb] print_thread_details_for_supposed_stack_address+0x8b (memMapPrinter.cpp:217) V [jvm.dll+0xc08ac4] MappingPrintSession::print_nmt_info_for_region+0x1f4 (memMapPrinter.cpp:260) V [jvm.dll+0xc09540] MemMapPrinter::pd_print_all_mappings+0x4c0 (memMapPrinter_windows.cpp:244) V [jvm.dll+0xc086ce] MemMapPrinter::print_all_mappings+0x7e (memMapPrinter.cpp:282) V [jvm.dll+0x60cbe7] SystemDumpMapDCmd::execute+0x67 (diagnosticCommand.cpp:1211) V [jvm.dll+0x60ffe5] DCmd::parse_and_execute+0x505 (diagnosticFramework.cpp:416) V [jvm.dll+0xbed5ad] jmm_ExecuteDiagnosticCommand+0x15d (management.cpp:2082) C 0x000001b72d9ae77e (no source info available)
19-09-2024
Deleted - wrong bug report
18-09-2024