On Wed, 4 Aug 2021 17:04:38 GMT, Thomas Stuefe <stu...@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
