Bug ID: JDK-8294519 (fs) java/nio/file/Files/CopyProcFile.java fails intermittenly due to unstable /proc/cpuinfo output

Versions (Unresolved/Resolved/Fixed)

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 20
20 b18Fixed

The new test from JDK-8293502 fails frequently, usually at high load. Fails reliably in tier2 testing for me:

$ CONF=linux-x86_64-server-fastdebug make test TEST=java/nio/file/Files/CopyProcFile.java

...

Using source file "/proc/cpuinfo"
Copied 98894 bytes from /proc/cpuinfo
config CopyProcFile.createBufferedCopy(): success
test CopyProcFile.testCopyAndTransfer(CopyProcFile$FHolder@bb8c28f): failure
java.nio.file.NoSuchFileException: bufferedCopy
	at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92)
	at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:106)
	at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)
	at java.base/sun.nio.fs.UnixFileSystemProvider.isSameFile(UnixFileSystemProvider.java:378)
	at java.base/java.nio.file.Files.isSameFile(Files.java:1538)
	at java.base/java.nio.file.Files.mismatch(Files.java:1590)
	at CopyProcFile.testCopyAndTransfer(CopyProcFile.java:168)


The real root cause is that test tries to copy from /proc/cpuinfo and check that copied contents are identical. The failure is obscure, because createBufferedCopy masks the initial copy check result by throwing RuntimeException, which the subsequent catch(Exception) block silently captures and deletes the bufferedCopy. Which means "config CopyProcFile.createBufferedCopy(): success" in the output above is actually misleading. 

But /proc/cpuinfo output is not guaranteed to be stable, because it includes CPU frequency. Simple test on my desktop:

$  while true; do cat /proc/cpuinfo > 1; sleep 1; cat /proc/cpuinfo > 2; diff -uwb 1 2; done
--- 1	2022-09-28 13:17:50.905173889 +0200
+++ 2	2022-09-28 13:17:51.929201003 +0200
@@ -5,7 +5,7 @@
 model name	: AMD Ryzen Threadripper 3970X 32-Core Processor
 stepping	: 0
 microcode	: 0x8301025
-cpu MHz		: 2263.655
+cpu MHz		: 2200.000
 cache size	: 512 KB
 physical id	: 0
 siblings	: 64

Changeset: a07975bf Author: Brian Burkhalter <bpb@openjdk.org> Date: 2022-09-29 21:06:49 +0000 URL: https://git.openjdk.org/jdk/commit/a07975bf3e321bdf02748693930c2523fa1df22d
29-09-2022
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/10479 Date: 2022-09-29 01:17:36 +0000
29-09-2022
It might not matter whether the test file /proc/<somefile> is tiny as we just want to ensure that something is read, not zero bytes like before.
28-09-2022
I wonder if we want to copy something large from /proc to exercise buffering? /proc/version is tiny. Let's problemlist the test (JDK-8294520), and see what options there are for test stabilization.
28-09-2022
/proc has been very troublesome because several system calls behave difference, you can't trust inode data, etc. I wonder if the test could use /proc/version as it should be stable.
28-09-2022