On Wed, 4 Aug 2021 12:22:24 GMT, Thomas Stuefe wrote:
> We should not leak the handle to the jimage file (lib/modules) to childs.
>
> JDK-8194734 did solve this for windows. We should use FD_CLOEXEC on Posix as
> well.
>
> Note that this only poses a problem when a child process is spawned
On Thu, 5 Aug 2021 14:06:17 GMT, Thomas Stuefe wrote:
>> 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
On Thu, 5 Aug 2021 13:13:27 GMT, Alan Bateman wrote:
>> 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
>>
On Wed, 4 Aug 2021 17:04:38 GMT, Thomas Stuefe 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
On Wed, 4 Aug 2021 13:35:59 GMT, Alan Bateman wrote:
>> We should not leak the handle to the jimage file (lib/modules) to childs.
>>
>> JDK-8194734 did solve this for windows. We should use FD_CLOEXEC on Posix as
>> well.
>>
>> Note that this only poses a problem when a child process is
We should not leak the handle to the jimage file (lib/modules) to childs.
JDK-8194734 did solve this for windows. We should use FD_CLOEXEC on Posix as
well.
Note that this only poses a problem when a child process is spawned off not via
`Runtime.exec` but via another route since the
On Wed, 4 Aug 2021 12:22:24 GMT, Thomas Stuefe wrote:
> We should not leak the handle to the jimage file (lib/modules) to childs.
>
> JDK-8194734 did solve this for windows. We should use FD_CLOEXEC on Posix as
> well.
>
> Note that this only poses a problem when a child process is spawned
