Exception raised when calling java.lang.Runtime.availableProcessors with native image

[hamsongliu]

Describe the issue
Caused by: java.lang.NullPointerException
at java.util.Objects.requireNonNull(Objects.java:208)
at sun.nio.fs.UnixFileSystem.getPath(UnixFileSystem.java:263)
at java.nio.file.Path.of(Path.java:147)
at java.nio.file.Paths.get(Paths.java:69)
at com.oracle.svm.core.containers.CgroupUtil.lambda$readStringValue$0(CgroupUtil.java:57)
at java.security.AccessController.executePrivileged(AccessController.java:145)
at java.security.AccessController.doPrivileged(AccessController.java:569)
at com.oracle.svm.core.containers.CgroupUtil.readStringValue(CgroupUtil.java:59)
at com.oracle.svm.core.containers.CgroupSubsystemController.getStringValue(CgroupSubsystemController.java:66)
at com.oracle.svm.core.containers.CgroupSubsystemController.getLongValue(CgroupSubsystemController.java:125)
at com.oracle.svm.core.containers.cgroupv1.CgroupV1Subsystem.getLongValue(CgroupV1Subsystem.java:269)
at com.oracle.svm.core.containers.cgroupv1.CgroupV1Subsystem.getCpuQuota(CgroupV1Subsystem.java:321)
at com.oracle.svm.core.containers.CgroupMetrics.getCpuQuota(CgroupMetrics.java:71)
at com.oracle.svm.core.ContainerInfo.getCpuQuota(ContainerInfo.java:41)
at com.oracle.svm.core.Containers.activeProcessorCount(Containers.java:127)
at java.lang.Runtime.availableProcessors(Runtime.java:241)

Steps to reproduce the issue
Create a native image which invokes "java.lang.Runtime.availableProcessors"

Describe GraalVM and your environment:

• openjdk version "17.0.3" 2022-04-19
• OpenJDK Runtime Environment GraalVM CE 22.1.0 (build 17.0.3+7-jvmci-22.1-b06)
• OpenJDK 64-Bit Server VM GraalVM CE 22.1.0 (build 17.0.3+7-jvmci-22.1-b06, mixed mode, sharing)
• OS: GNU/Linux
• Architecture: x86_64

[oubidar-Abderrahim]

Hi, Thank you for reporting this, could you please provide a small reproducer for this

[Ruj89]

Same error when try to run a native docker image of a Quarkus application.
I'm not sure why that happens, in my case maybe because I set the compiler version to Java 11. I fixed using the Quarkus Java 11 builder image command line flag
mvn package -Pnative -Dquarkus.native.builder-image=quay.io/quarkus/ubi-quarkus-native-image:22.2-java11
I should try to update the whole project to Java 17.

[cushon]

I ran into the same stack trace. I wasn't able to put together a minimal repro, but I'm only seeing this when running in a containerized environment, and passing -H:-UseContainerSupport to native-image works around the crash

[gunnarmorling]

Running into this too, when trying to deploy a GraalVM (22.3.0) native application (built with Quarkus) via Docker on render.com. IIUC, this is triggered by unconditionally trying to retrieve CPU quotas for the current container, which may or may not be set (and apparently are not set on render.com).

[gunnarmorling]

This might be an equivalent to https://bugs.openjdk.org/browse/JDK-8272124 in OpenJDK, which is triggered by cgroup paths containing a colon.

[jerboaa]

Yes it's GraalVM's version of https://bugs.openjdk.org/browse/JDK-8272124 (at least very likely). The code is not very much up to date in that space and largely duplicates JDK code. To confirm, please paste /proc/self/cgroup on those deployments if you can.

[gunnarmorling]

To confirm, please paste /proc/self/cgroup on those deployments if you can.

This is what I see there (sans some identifying UUIDs/SHAs):

13:blkio:/system.slice/containerd.service/kubepods-burstable-pod<redacted>.slice:cri-containerd:<redacted>
12:hugetlb:/kubepods-burstable-pod<redacted>.slice:cri-containerd:<redacted>
11:misc:/
10:devices:/system.slice/containerd.service/kubepods-burstable-pod<redacted>.slice:cri-containerd:<redacted>
9:cpu,cpuacct:/system.slice/containerd.service/kubepods-burstable-pod<redacted>.slice:cri-containerd:<redacted>
8:rdma:/
7:pids:/system.slice/containerd.service/kubepods-burstable-pod<redacted>.slice:cri-containerd:<redacted>
6:perf_event:/kubepods-burstable-pod<redacted>.slice:cri-containerd:<redacted>
5:net_cls,net_prio:/kubepods-burstable-pod<redacted>.slice:cri-containerd:<redacted>
4:freezer:/kubepods-burstable-pod<redacted>.slice:cri-containerd:<redacted>
3:memory:/system.slice/containerd.service/kubepods-burstable-pod<redacted>.slice:cri-containerd:<redacted>
2:cpuset:/kubepods-burstable-pod<redacted>.slice:cri-containerd:<redacted>
1:name=systemd:/system.slice/containerd.service/kubepods-burstable-pod<redacted>.slice:cri-containerd:<redacted>
0::/system.slice/containerd.service

[jerboaa]

Hmm, it might be JDK-8272124 or any number of other bugs. My attempts at reproducing this using the repro of JDK-8272124 still failed, though. That bug is present, as it reports a wrong limit, but it doesn't produce the NPE.

If somebody could paste /proc/cgroups and /proc/self/mountinfo as well, we might be able to reproduce in a specially crafted test.

[jerboaa]

Some evidence of JDK-8272124:

$ cat Test.java 
public class Test {
	public static void main(String[] args) {
		System.out.println("cpus = " + Runtime.getRuntime().availableProcessors());
	}
}

Produce a native image from it and compare Java vs native image runs with (expected 3 cpu cores, actually produces host number of CPU cores):

$ sudo podman run --cpu-period 100000 --cpu-quota=300000 --memory=200m --cgroup-manager=cgroupfs --cgroup-parent="/opt/foo/bar:baz" -v $(pwd):/test:z -v /disk/openjdk/17.0.5/:/opt/jdk:z --rm -ti fedora:37
[root@6f8808bd30e3 /]# /test/npe-colon-test 
cpus = 12
[root@6f8808bd30e3 /]# /opt/jdk/bin/java -cp /test Test
cpus = 3
[root@6f8808bd30e3 /]# /opt/jdk/bin/java -XX:-UseContainerSupport -cp /test Test
cpus = 12