The bug is similar to JDK-8237858.

In fileDescriptorClose(), if close() returns -1, IOException is thrown.
However, when profiling application with a signal-based mechanism, close() can be interrupted by a signal and return -1 with errno=EINTR. This happens when the underlying file system is a network file system, e.g. CIFS.

The problem was originally reported against async-profiler:
https://github.com/jvm-profiling-tools/async-profiler/issues/384

I can always reproduce the bug with the following simple program:

public class CifsBug {

    public static void main(String[] args) throws Exception {
        byte[] buf = new byte[65536];
        ThreadLocalRandom.current().nextBytes(buf);

        for (int fileId = 0; fileId < 1000; fileId++) {
            System.out.println("Writing " + fileId);
            try (FileOutputStream out = new FileOutputStream("/mnt/cifs/tmp" + fileId + ".tmp")) {
                out.write(buf, 0, buf.length);
                System.out.println("Closing " + fileId);
            }
        }
    }
}

When I run it with -agentlib:asyncProfiler=start,event=cpu,interval=1ms the program eventually throws IOException:

Exception in thread "main" java.io.IOException: Interrupted system call
        at java.base/java.io.FileDescriptor.close0(Native Method)
        at java.base/java.io.FileDescriptor.close(FileDescriptor.java:297)
        at java.base/java.io.FileOutputStream$1.close(FileOutputStream.java:390)
        at java.base/java.io.FileDescriptor.closeAll(FileDescriptor.java:355)
        at java.base/java.io.FileOutputStream.close(FileOutputStream.java:388)
        at CifsBug.main(CifsBug.java:15)

Linux man page for close() explicitly mentions that close() may return errno=EINTR: https://man7.org/linux/man-pages/man2/close.2.html
So, JDK should handle EINTR in fileDescriptorClose() and silently ignore it on Linux, just like UnixNativeDispatcher_close0 already does.