JDK-8269074 : (fs) Files.copy fails to copy from /proc on some linux kernel versions
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.nio
  • Affected Version: 18
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • Submitted: 2021-06-21
  • Updated: 2021-07-15
  • Resolved: 2021-06-25
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 17 JDK 18
17 b29Fixed 18Fixed
Related Reports
Relates :  
JDK-8265175 - (fs) Files.copy(Path,Path,CopyOption...) should use sendfile on Linux
Description
This has been initially observed with the test case runtime/os/TestTracePageSizes on a debian testing.
$ uname -srv
Linux 5.10.0-6-amd64 #1 SMP Debian 5.10.28-1 (2021-04-09)

Tests is test/jdk/java/nio are all passing.

java.nio.file.FileSystemException: /proc/self/smaps -> smaps-copy-31084-0.txt: Invalid argument
	at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:100)
	at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:106)
	at java.base/sun.nio.fs.UnixCopyFile.copyFile(UnixCopyFile.java:256)
	at java.base/sun.nio.fs.UnixCopyFile.copy(UnixCopyFile.java:603)
	at java.base/sun.nio.fs.UnixFileSystemProvider.copy(UnixFileSystemProvider.java:258)
	at java.base/java.nio.file.Files.copy(Files.java:1305)
	at TestTracePageSizes.copySmaps(TestTracePageSizes.java:122)
	at TestTracePageSizes.parseSmaps(TestTracePageSizes.java:134)
	at TestTracePageSizes.main(TestTracePageSizes.java:258)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
	at java.base/java.lang.Thread.run(Thread.java:833)

The man page says:

EINVAL Descriptor  is  not valid or locked, or an mmap(2)-like operation is not available for in_fd, or count is negative.

Probably, an fd pointing to a file in /proc does not support mmap like operations on all kernel versions.
Comments
Changeset: 5ebed06e Author: Brian Burkhalter <bpb@openjdk.org> Date: 2021-06-25 19:06:42 +0000 URL: https://git.openjdk.java.net/jdk17/commit/5ebed06e8ae27ca73433497b4e4aa559d06ed8ec
25-06-2021
On Ubuntu 20.04 setting /dev/null as the source does not provoke EINVAL.
22-06-2021
I think the important part is to test if the fallback routine is used or not. Maybe using a another type of special file as the source FD for sendfile also returns EINVAL? I tested /dev/null and sendfile returns EINVAL for that one as well. No sure if Files.copy should work with it, but I guess before the sendfile implementation, it did. I am also not sure if this is again something special for my kernel version or not.
22-06-2021
Concerning the noreg-hard label, it would be difficult to create a test to provoke this failure without having available a Linux version for which the problem occurs. The Hotspot test mentioned in the description [1] did however catch the failure when run on the reporter's own system. [1] test/hotspot/jtreg/runtime/os/TestTracePageSizes.java
21-06-2021
The original proposal for using sendfile fell back to user-space buffers but that was removed in the course of the review [1]. Probably it should do this on both Linux and macOS. [1] https://github.com/openjdk/jdk/pull/3476
21-06-2021
Files.copy is supposed to fallback to transfer via user-spec buffers when sendfile not supported so there may be an issue there.
21-06-2021