JDK-8237872 : runtime/NMT/ThreadedVirtualAllocTestType.java test failure in JDK 15
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 11,15
  • Priority: P3
  • Status: Closed
  • Resolution: Won't Fix
  • Submitted: 2020-01-27
  • Updated: 2024-10-18
  • Resolved: 2021-10-12
Related Reports
Relates :  
JDK-8251392 - Consolidate Metaspace Statistics
Relates :  
JDK-8266183 - Provide an API to get statistics from metaspace in a consistent manner
Description
Following failure reported with JDK 15 CI testing - 
test - runtime/NMT/ThreadedVirtualAllocTestType.java

  with linux-x64-debug
  with -Xcomp -XX:+CreateCoredumpOnCrash -ea -esa -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -server -XX:-TieredCompilation -XX:-UseCompressedOops


      ExitCode: 134
      Crash: Internal Error ...memReporter.cpp...assert(committed >= used + free) failed: Sanity
      Crash: V ...[libjvm.so+...] MemSummaryReporter::report_summary_of_type(MemoryType, MallocMemory*, VirtualMemory*)+...


------------------
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (open/src/hotspot/share/services/memReporter.cpp:226), pid=1437, tid=1609
#  assert(committed >= used + free) failed: Sanity
#
# JRE version: Java(TM) SE Runtime Environment (15.0+8) (fastdebug build 15-ea+8-182)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 15-ea+8-182, compiled mode, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x112f1d0]  MemSummaryReporter::report_summary_of_type(MemoryType, MallocMemory*, VirtualMemory*)+0xab0
#
..............
---------------  T H R E A D  ---------------

Current thread (0x00007f1bac001000):  JavaThread "Attach Listener" daemon [_thread_in_vm, id=1609, stack(0x00007f1b9f8fa000,0x00007f1b9f9fb000)]

Stack: [0x00007f1b9f8fa000,0x00007f1b9f9fb000],  sp=0x00007f1b9f9f91d0,  free space=1020k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x112f1d0]  MemSummaryReporter::report_summary_of_type(MemoryType, MallocMemory*, VirtualMemory*)+0xab0
V  [libjvm.so+0x112f5cc]  MemSummaryReporter::report()+0x33c
V  [libjvm.so+0x11f9455]  NMTDCmd::report(bool, unsigned long)+0x4c5
V  [libjvm.so+0x11f9ec8]  NMTDCmd::execute(DCmdSource, Thread*)+0x448
V  [libjvm.so+0x988ea7]  DCmd::parse_and_execute(DCmdSource, outputStream*, char const*, char, Thread*)+0x1d7
V  [libjvm.so+0x534307]  jcmd(AttachOperation*, outputStream*)+0x47
V  [libjvm.so+0x536515]  attach_listener_thread_entry(JavaThread*, Thread*)+0x3c5
V  [libjvm.so+0x1534136]  JavaThread::thread_main_inner()+0x226
V  [libjvm.so+0x15392c6]  Thread::call_run()+0xf6
V  [libjvm.so+0x126ecce]  thread_native_entry(Thread*)+0x10e
Comments
Runtime Triage: This is not on our current list of priorities. We will consider this feature if we receive additional customer requirements.
12-10-2021
Regarding the fix version field; JDK 11 and JDK 15 have already been released so no fix can be pushed there. Please use 11-pool or 15-pool (or a specific future release) for the fix version. Also, please set just one fix version per bug. If fixing in both 11u and 15u is desired then set this bug to 15-pool, and create a backport issue for 11-pool.
04-05-2021
This is a known issue. Its a broken pattern used in various places (see e.g. https://bugs.openjdk.java.net/browse/JDK-8151460, where it is used in MetaspaceCounters::update_performance_counters()). I'll fix this in head by adding a combined API which returns guaranteed consistent values. However, this specific problem in NMT reporting should not occur in head in JDK16++. So there is no point in fixing it in 17. I am hesitant about fixing this in pre-JEP 387 coding at all. It has not bugged us much for the last 10 years since Metaspace was invented.
28-04-2021
[~stuefe] I am looking at following code segment: size_t committed = MetaspaceUtils::committed_bytes(type); size_t used = MetaspaceUtils::used_bytes(type); size_t free = (MetaspaceUtils::capacity_bytes(type) - used) + MetaspaceUtils::free_chunks_total_bytes(type) + MetaspaceUtils::free_in_vs_bytes(type); assert(committed >= used + free, "Sanity"); Seems individual values are retrieved without any lock, the values can be inherited racy. Is any lock we can take to ensure the integrity of the values. Thanks.
06-02-2020
[~zgu] Thanks for taking a look at it.
28-01-2020
[~mseledtsov] I could not reproduce in a loop with 10 iterations locally. This bug, along with JDK-8235180, seems to be in metaspace counting code, where [~stuefe] is the expert, probably should have him to take a look.
28-01-2020
[~zgu] Would you mind taking a look at this?
28-01-2020
Not likely a test bug. ILW: HLM: P3
28-01-2020