JDK-8229284 : [TESTBUG] jdk/internal/platform/cgroup/TestCgroupMetrics.java fails for - memory:getMemoryUsage
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: openjdk8u292,13,14
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • CPU: generic
  • Submitted: 2019-08-08
  • Updated: 2024-06-04
  • Resolved: 2019-08-29
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 JDK 8 Other
11.0.12-oracleFixed 13.0.2Fixed 14 b13Fixed 8u361Resolved openjdk8u292Fixed
Related Reports
Relates :  
Description
We sometimes see failures in the jtreg test jdk/internal/platform/cgroup/TestCgroupMetrics.java  .
Failures look like :

java.lang.RuntimeException: Test failed for - memory:getMemoryUsage, expected [56019386368], got [56200986624]
	at jdk.test.lib.containers.cgroup.MetricsTester.fail(MetricsTester.java:207)
	at jdk.test.lib.containers.cgroup.MetricsTester.testMemoryUsage(MetricsTester.java:597)
	at TestCgroupMetrics.main(TestCgroupMetrics.java:53)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:567)
	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
	at java.base/java.lang.Thread.run(Thread.java:830)


Looking at the coding in MetricsTester.java  we expect that “memory.usage_in_bytes”  gets larger after an additional allocation of 64 M.
However this is sometimes not the case. The reason is not fully clear.
Might be that a GC kicked in and freed space;  or for some reasons OS pages were freed.
Maybe also the "memory.usage_in_bytes”  counter is not so reliable (by design? or bug ?) .
Coding from  MetricsTester.java :

    public void testMemoryUsage() throws Exception {
        Metrics metrics = Metrics.systemMetrics();
        long memoryMaxUsage = metrics.getMemoryMaxUsage();
        long memoryUsage = metrics.getMemoryUsage();

        byte[] bb = new byte[64*1024*1024]; // 64M  - here we expect an increase of  memory.usage_in_bytes

        long newMemoryMaxUsage = metrics.getMemoryMaxUsage();
        long newMemoryUsage = metrics.getMemoryUsage();

        if(newMemoryMaxUsage < memoryMaxUsage) {
            fail(SubSystem.MEMORY, "getMemoryMaxUsage", newMemoryMaxUsage,
                    memoryMaxUsage);
        }

        if(newMemoryUsage < memoryUsage) {
            fail(SubSystem.MEMORY, "getMemoryUsage", newMemoryUsage, memoryUsage);   // line 597  triggers the failure in MetricsTester.java
        }
    }


probably we should make the test more reliable and add a little loop with allocations (and do not fail on the first one) .
Comments
Fix request (11u): The test failure is observed in JDK 11u testing, too. Patch applies cleanly after applying JDK-8224502 and JDK-8227642. It fixes these intermittent test failures. Risk is low.
24-09-2019

Fix request (jdk13): The test failure is observed in JDK13u testing, too. Patch applies cleanly and fixes these intermittent test failures. Risk is low.
23-09-2019

URL: https://hg.openjdk.java.net/jdk/jdk/rev/72bc9a29fd7e User: mbaesken Date: 2019-08-29 15:51:07 +0000
29-08-2019