RFR: 8373867: Improve robustness of Attach API for finding tmp directory

Yasumasa Suenaga ysuenaga at openjdk.org
Fri Dec 19 14:14:59 UTC 2025


On Thu, 18 Dec 2025 13:37:50 GMT, Sebastian Lövdahl <duke at openjdk.org> wrote:

>> @slovdahl I found out the cause of error in TestJcmdWithSideCar.java. It is not a bug, environment issue.
>> I sent email to serviceability-dev because it is different from this PR.
>> https://mail.openjdk.org/pipermail/serviceability-dev/2025-December/068668.html
>> 
>> Anyway, I'm waiting for Reviewers for this PR!
>
> @YaSuenag Interesting, thanks for figuring that part out.
> 
> In any case, I also ran the tests locally now (using Docker 29.1.3 on Ubuntu 24.04), both on the latest JDK master branch and on your branch. Both passed.
> 
> 
> make test TEST=test/hotspot/jtreg/containers/docker/TestJcmdWithSideCar.java JTREG=RUN_PROBLEM_LISTS=true
> 
> 
> But on another note, I'm wondering if this change breaks the fix from https://bugs.openjdk.org/browse/JDK-8226919 and https://github.com/openjdk/jdk/pull/17628.
> 
> Unfortunately there is no jtreg test for it, but by following the steps I did in https://github.com/openjdk/jdk/pull/17628#issuecomment-1916589081 and trying to attach to a JVM run as a systemd unit with extra privileges using a JDK built from this branch, I got this error:
> 
> 
> [15:35:41] ~/dev/external/jdk-8226919-reproducer ❯ /home/slovdahl/dev/external/jdk/build/linux-x86_64-server-release/images/jdk/bin/java -version
> openjdk version "27-internal" 2026-09-15
> OpenJDK Runtime Environment (build 27-internal-adhoc.slovdahl.jdk)
> OpenJDK 64-Bit Server VM (build 27-internal-adhoc.slovdahl.jdk, mixed mode, sharing)
> 
> [15:30:58] ~/dev/external/jdk-8226919-reproducer ❯ /home/slovdahl/dev/external/jdk/build/linux-x86_64-server-release/images/jdk/bin/jcmd $(pgrep -f Reproducer.java) VM.version
> 2799281:
> com.sun.tools.attach.AttachNotSupportedException: Unable to access the filesystem of the target process
>         at jdk.attach/sun.tools.attach.VirtualMachineImpl.findTargetProcessTmpDirectory(VirtualMachineImpl.java:281)
>         at jdk.attach/sun.tools.attach.VirtualMachineImpl.findSocketFile(VirtualMachineImpl.java:231)
>         at jdk.attach/sun.tools.attach.VirtualMachineImpl.<init>(VirtualMachineImpl.java:82)
>         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)
> Caused by: java.nio.file.AccessDeniedException: /proc/2799281/root/tmp
>         at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:90)
>         at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:108)
>         at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:113)
>         at java.base/sun.nio.fs.UnixFileSystemProvider.isSameFile(UnixFileSystemProvider.java:391)
>         at java.base...

@slovdahl 
I fix the problem, and I added new testcase as TestWithoutDumpableProcess.java which covers your use case.
I reproduce the problem which is same situation with your case with `prctl()` with `PR_SET_DUMPABLE`. if `PR_SET_DUMPABLE` is disabled, most of file owner in procfs is root and we cannot access /proc/<PID>/root even though `jcmd` lists the process. New testcase call `prctl` via FFM.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28867#issuecomment-3675225882


More information about the core-libs-dev mailing list