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?


> -----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