RFR 8177932 (process) java/lang/ProcessHandle/OnExitTest.java failed with "Process A should not be alive"
Frank Yuan
frank.yuan at oracle.com
Wed Sep 6 05:41:37 UTC 2017
Hi Roger
I think this is the cause and I believe the patch will work.
However, I have the following concern and minor comments:
a. Is it possible that following scenario happens?
1. process A exits
2. Completion thread in onExist runs and gets 0 as origStart, and then sleeps 5s
3. process reaper thread reaps the process A, and then the pid is reused
4. Completion thread gets a value as startTime, and then has to wait the new process termination
I am not sure if the startTIme may be zero except the process is a zombie, if the startTIme may be zero only when the process is a zombie, we can change the condition to: if (startTime > 0 && startTime != origStart), otherwise we can't avoid such scenario, but if ProcessHandleImpl.onExit() passes startTime field to function completion, it may be a little bit better, at least, onExit() can be consistent with isAlive().
b. Should we rollback the change of JDK-8184808, at least, update the comment in that change?
c. Should we remove @key intermittent and the debug info added in JDK-8183019?
Thanks
Frank
> -----Original Message-----
> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf Of Roger Riggs
> Subject: RFR 8177932 (process) java/lang/ProcessHandle/OnExitTest.java failed with "Process A should not be alive"
>
> Please review a fix for an intermittent issue with ProcessHandle.onExit.
> On Solaris, the start time of a process reported through
> /proc/pid/psinfo changes to
> zero when the process is exiting. The onExit implementation incorrectly
> interpreted zero
> meaning the pid had been re-used and the process was no longer alive.
> However,
> ProcessHandle.isAlive considered zero to be missing information and the
> process was still alive.
>
> Webrev:
> http://cr.openjdk.java.net/~rriggs/webrev-onexit-8177932/
>
> Issue:
> https://bugs.openjdk.java.net/browse/JDK-8177932
>
> Thanks, Roger
More information about the core-libs-dev
mailing list