RFR: JDK-8271858: Handle to jimage file inherited into child processes (posix)

Alan Bateman alanb at openjdk.java.net
Thu Aug 5 13:16:46 UTC 2021


On Wed, 4 Aug 2021 17:04:38 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> src/java.base/unix/native/libjimage/osSupport_unix.cpp line 41:
>> 
>>> 39:  */
>>> 40: jint osSupport::openReadOnly(const char *path) {
>>> 41:     return ::open(path, O_CLOEXEC);
>> 
>> This is okay but I think it would be useful to know why this one place needs O_CLOEXEC and not others.
>
> Probably others too, if we care about inheriting read handles to child.
> 
> The background is that I am playing with a new test which checks that the VM has no open inheritable file descriptors. It is supposed to replace some specialized tests which are maintenance-intensive. I am still tuning the test, since at the moment it turns out too many false positives.
> 
> Anyway, this is the very first descriptor the VM opens, therefore it triggered my test. I thought since there is a sibling fix for windows, a similar fix for posix would be symmetric.
> 
> If you think this is not worth fixing, or we should fix all occurrences in one swoop, that is fine too.

On Unix systems, the JDK has always relied on the Runtime.exec implementation to close the file descriptors. On Windows the inheritance has to be disabled in the parent. So if the gtest launcher is forking directly then we may have a bit of whack-a-mole to change all the places that open file descriptors.

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

PR: https://git.openjdk.java.net/jdk/pull/4991


More information about the core-libs-dev mailing list