JDK-8287073 : NPE from CgroupV2Subsystem.getInstance()
  • Type: Bug
  • Component: core-libs
  • Affected Version: 11.0.16,17.0.3,18.0.2,19
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: linux
  • Submitted: 2022-05-20
  • Updated: 2023-08-11
  • Resolved: 2022-05-30
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 17 JDK 19 JDK 8 Other
11.0.17Fixed 17.0.5Fixed 19 b25Fixed 8u381Fixed openjdk8u392Fixed
Related Reports
Relates :  
JDK-8287663 - Add a regression test for JDK-8287073
Relates :  
JDK-8286212 - Cgroup v1 initialization causes NPE on some systems
Description
The following is an error reported by a customer of the Toolbox app:

Cannot invoke "jdk.internal.platform.CgroupInfo.getMountPoint()" because "<parameter1>" is null: java.lang.NullPointerException: Cannot invoke "jdk.internal.platform.CgroupInfo.getMountPoint()" because "<parameter1>" is null
	at java.base/jdk.internal.platform.cgroupv2.CgroupV2Subsystem.getInstance(Unknown Source)
	at java.base/jdk.internal.platform.CgroupSubsystemFactory.create(Unknown Source)
	at java.base/jdk.internal.platform.CgroupMetrics.getInstance(Unknown Source)
	at java.base/jdk.internal.platform.SystemMetrics.instance(Unknown Source)
	at java.base/jdk.internal.platform.Metrics.systemMetrics(Unknown Source)
	at java.base/jdk.internal.platform.Container.metrics(Unknown Source)
	at jdk.management/com.sun.management.internal.OperatingSystemImpl.<init>(Unknown Source)
	at jdk.management/com.sun.management.internal.PlatformMBeanProviderImpl.getOperatingSystemMXBean(Unknown Source)
	at jdk.management/com.sun.management.internal.PlatformMBeanProviderImpl$3.nameToMBeanMap(Unknown Source)
	at java.management/sun.management.spi.PlatformMBeanProvider$PlatformComponent.getMBeans(Unknown Source)
	at java.management/java.lang.management.ManagementFactory.getPlatformMXBean(Unknown Source)
	at java.management/java.lang.management.ManagementFactory.getOperatingSystemMXBean(Unknown Source)
	at com.jetbrains.toolbox.PerformanceMetricsImpl.<init>(PerformanceMetrics.kt:19)
	at com.jetbrains.toolbox.interop.cef.NativeGUIProcessKt.createToolboxServices(NativeGUIProcess.kt:177)
	at com.jetbrains.toolbox.entry.ToolboxEntry.startToolbox(toolbox-process-entry.kt:73)
Comments
Fix Request (OpenJDK 8u): Please approve this low-risk bugfix in the JDK's init routine for the container detection code. Patch is clean modulo path shuffeling. 8u code is affected as well. It's usually called when the OSMXBean is being used which is container aware. The change is to use any one of the controllers (instead of hard-coding it to the memory controller). That's more resilient than the current status. A backport of the regression test for this via JDK-8287663 in in the approval queue as well. Container tests continue to pass for me on x86_64 on cg1 and cg2.
26-05-2023
A pull request was submitted for review. URL: https://git.openjdk.org/jdk8u-dev/pull/324 Date: 2023-05-26 14:46:38 +0000
26-05-2023
Fix Request (OpenJDK 11u): Please approve this low-risk bugfix in the JDK's init routine for the container detection code. Code is affected as well. It's usually called when the OSMXBean is being used which is container aware. The change is to use any one of the controllers (instead of hard-coding it to the memory controller). That's more resilient than the current status. I intend to also backport the regression test for this via JDK-8287663. Container tests continue to pass for me on x86_64 on cg1 and cg2.
25-08-2022
A pull request was submitted for review. URL: https://git.openjdk.org/jdk11u-dev/pull/1339 Date: 2022-08-24 14:59:26 +0000
24-08-2022
Fix Request (OpenJDK 17u): Please approve this low-risk bugfix in the JDK's init routine for the container detection code. It's usually called when the OSMXBean is being used which is container aware. The change is to use any one of the controllers (instead of hard-coding it to the memory controller). That's more resilient than the current status. I intend to also backport the regression test for this via JDK-8287663. Container tests continue to pass for me on x86_64 on cg1 and cg2.
10-06-2022
A pull request was submitted for review. URL: https://git.openjdk.java.net/jdk17u-dev/pull/456 Date: 2022-06-09 11:54:27 +0000
09-06-2022
Changeset: 744b822a Author: Maxim Kartashev <mkartashev@openjdk.org> Committer: Ioi Lam <iklam@openjdk.org> Date: 2022-05-30 06:18:47 +0000 URL: https://git.openjdk.java.net/jdk/commit/744b822ab194a0f7ef4e7a4053be32c6a0889efc
30-05-2022
A pull request was submitted for review. URL: https://git.openjdk.java.net/jdk/pull/8803 Date: 2022-05-20 08:34:58 +0000
20-05-2022
The only reason for this to occur that I can see from reading the code is the absence of the "memory" cgroup that is being used as a "sample" cgroup in CgroupSubsystemFactory.create() around here: Map<String, CgroupInfo> infos = result.getInfos(); if (result.isCgroupV2()) { // For unified it doesn't matter which controller we pick. CgroupInfo anyController = infos.get(MEMORY_CTRL); // <<<< this controller may not be there CgroupSubsystem subsystem = CgroupV2Subsystem.getInstance(anyController); return subsystem != null ? new CgroupMetrics(subsystem) : null; I was unable to reproduce the error (tried switching off the memory controller with a kernel option, building a customer kernel without the memory controller support, booting Ubuntu 22.04 in WSL2).
20-05-2022