On Sat, 9 Aug 2025 19:50:14 GMT, Philippe Marschall <d...@openjdk.org> wrote:
> Reduce the usage of JNI in the Linux attach provider by making more use of > the `Path` API. > > - use the `Path` API to read file permissions > - use the `Path` API to write to and read from Unix domain sockets > - use JDK internal APIs to access the euid and eguid > > After this the sole usage of JNI in the Linux attach provider will be to send > a signal using `kill`. > > I ran the tier1 and serviceability test suites and they both pass. I verified > I can attach to and attach using a locally built JDK. I didn't do any Docker > related tests. > > I split the changes into two commits: > > - The first commit ports the permission check code more or less directly from > C to Java using integer based checks. > - The second commit changes the permission check code to use higher level > Java abstractions (`UserPrincipal`, `Set`, ...) > > I hope this makes it easier to review and verify the changes preserve the > semantics. > > To the best of my knowledge `uid_t` is an unsigned 32 bit integer. > `VM#geteuid()` returns it as `long`, unsigned. However > `UnixUserPrincipals#fromUid` expects an `int`, I believe casting is the > correct way to convert in this case. > > I tried to keep unrelated changes to `VirtualMachineImpl` to a minimum. I did > however replace all usages of `java.io.File` with `java.nio.file.Path` and > made two methods `static`. We could get rid of the `socket_path` instance > variable if we instead use `socket_address` to flag a disconnect. > > Ultimately the same changes can be applied to the macOS an AIX > implementations. > Thanks for the work so far, nice to get rid of JNI. 🙂 > > There is a [problemlisted test](https://github.com/openjdk/jdk/pull/21417) > related to this that could make sense to run manually > (https://bugs.openjdk.org/browse/JDK-8341518, it's failing in Oracle's CI but > I have not been able to reproduce the failure myself, discussed a bit in > #21331 too). > > I'll see if I can find time to check out this change locally and run some > tests, otherwise, feel free to run it yourself. TestJcmdWithSideCar fails with java.nio.file.NoSuchFileException: /proc/7/cwd/.attach_pid7 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.UnixPath.toRealPath(UnixPath.java:856) at jdk.attach/sun.tools.attach.VirtualMachineImpl.<init>(VirtualMachineImpl.java:106) at jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:56) at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:201) at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:113) at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:97) I must confess I'm quite confused by this as this ultimately means that Files.createFile(path).toRealPath() Fails with NoSuchFileException on the Path returned by createFile. Is there a better way to run TestJcmdWithSideCar other than removing it from ProblemList? As for the issue on Oralce CI, is there I way I ran run TestJcmdWithSideCar on a feature branch of mine on Oralce CI without opening a PR? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26712#issuecomment-3185276826
