8381567: ProcessHandle.descendants fails with ArrayIndexOutOfBoundException for process 0 by Michael-Mc-Mahon · Pull Request #30763 · openjdk/jdk

Michael-Mc-Mahon · 2026-04-16T10:55:38Z

Hi,

This is a small fix for j.l.ProcessHandle on MacOS. Unlike other platforms, Mac returns a ProcessHandle for pid 0 whose descendants are all processes on the system. This specific scenario tickles an off by one error where the descendants method tries to access an element past the end of the array of pids. The fix is to break from the loop before accessing this element.

Thanks,

Michael

I confirm that I make this contribution in accordance with the OpenJDK Interim AI Policy.

Progress

Change must be properly reviewed (1 review required, with at least 1 Reviewer)
Change must not contain extraneous whitespace
Commit message must refer to an issue

Issue

JDK-8381567: ProcessHandle.descendants fails with ArrayIndexOutOfBoundException for process 0 (Bug - P4)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/30763/head:pull/30763
$ git checkout pull/30763

Update a local copy of the PR:
$ git checkout pull/30763
$ git pull https://git.openjdk.org/jdk.git pull/30763/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 30763

View PR using the GUI difftool:
$ git pr show -t 30763

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/30763.diff

Using Webrev

Link to Webrev Comment

bridgekeeper · 2026-04-16T10:57:09Z

👋 Welcome back michaelm! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

openjdk · 2026-04-16T10:58:11Z

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

openjdk · 2026-04-16T10:59:29Z

@Michael-Mc-Mahon The following labels will be automatically applied to this pull request:

core-libs
nio

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing lists. If you would like to change these labels, use the /label pull request command.

mlbridge · 2026-04-16T11:04:15Z

Webrevs

AlanBateman · 2026-04-16T11:06:58Z

/label remove nio

openjdk · 2026-04-16T11:08:30Z

@AlanBateman
The nio label was successfully removed.

RogerRiggs · 2026-04-16T12:19:30Z

                }
            }
-            ppid = pids[++count];   // pick up the next pid to scan for
+            if (++count >= size) {


Do the check without incrementing and increment below.
It looks odd to bump the count even though it's not used.

Marcono1234 · 2026-04-16T12:46:36Z

+
+import org.junit.jupiter.api.Test;
+
+/*


Should this have a @bug tag?

Marcono1234 · 2026-04-16T12:49:33Z

+     */
+    @Test
+    public void test() {
+         int num = ProcessHandle.of(0).orElseThrow().descendants().toList().size();


Should this have any assertion? E.g. assertNotEquals(0, num) / assertTrue(num > 0) (or at least a assertDoesNotThrow to clarify the intention)?

I can wrap the invocation in assertDoesNotThrow()

AlanBateman · 2026-04-16T16:40:32Z

+            }
            ppid = pids[++count];   // pick up the next pid to scan for
            ppStart = starttimes[count];    // and its start time
        } while (count < next);


Have you tried } while (count < next && count < (size -1)) to avoid the break out of the loop.

Have you tried } while (count < next && count < (size -1)) to avoid the break out of the loop.

It has already dereferenced the invalid index at that point. It might be possible to restructure the loop by putting the assignment to ppid and ppStart at the top, but the initial value for ppid is not taken from the array, which is probably why that code is at the end of the loop.

Co-authored-by: Andrey Turbanov <turbanoff@gmail.com>

RogerRiggs · 2026-04-18T16:52:37Z

The purpose of the do{...} while loop is to sort the descendants to the beginning of the arrays.
If the desired result for pid == 0 is to return all processes, then it should not be wasting time selecting and sorting.
Just return a Stream of all of the ProcessHandles (or skip the sorting).

Michael-Mc-Mahon · 2026-04-20T07:19:26Z

The purpose of the do{...} while loop is to sort the descendants to the beginning of the arrays. If the desired result for pid == 0 is to return all processes, then it should not be wasting time selecting and sorting. Just return a Stream of all of the ProcessHandles (or skip the sorting).

I wouldn't say that is desired behavior. It's just what is observed but is platform specific and undocumented. I'm not sure special casing pid == 0 in the shared code is a good idea. What if the other platforms have similar behavior, but for different pid values? I think also checking before dereferencing an out of range index value is still prudent regardless.

RogerRiggs · 2026-04-21T15:49:25Z

I wouldn't say that is desired behavior. It's just what is observed but is platform specific and undocumented. I'm not sure special casing pid == 0 in the shared code is a good idea. What if the other platforms have similar behavior, but for different pid values? I think also checking before dereferencing an out of range index value is still prudent regardless.

getDescendents() does not expect to find the requested pid in the result stream/list.
The use of zero in the call to native is intended to fetch info for all processes.

Hmm, I don't think process 0 is real and am surprised to find a process zero with parent zero in the result list.
I don't have a Linux handy to check. ps on MacOS does not list it. ps -p 0.
Process ids are OS specific so there is no spec to throw IAE on ProcessHandle.of(0).
But I don't think pid zero should be exposed.

If a process zero is not real then the API should return an empty list for calls to ProcessHandle.of(0).getDescendents().toList().

Michael-Mc-Mahon · 2026-04-21T16:28:25Z

I wouldn't say that is desired behavior. It's just what is observed but is platform specific and undocumented. I'm not sure special casing pid == 0 in the shared code is a good idea. What if the other platforms have similar behavior, but for different pid values? I think also checking before dereferencing an out of range index value is still prudent regardless.

getDescendents() does not expect to find the requested pid in the result stream/list. The use of zero in the call to native is intended to fetch info for all processes.

Hmm, I don't think process 0 is real and am surprised to find a process zero with parent zero in the result list. I don't have a Linux handy to check. ps on MacOS does not list it. ps -p 0. Process ids are OS specific so there is no spec to throw IAE on ProcessHandle.of(0). But I don't think pid zero should be exposed.

If a process zero is not real then the API should return an empty list for calls to ProcessHandle.of(0).getDescendents().toList().

ProcessHandle.of(0) returns a real handle on Mac, but not on Linux or Windows. We could disallow its creation on Mac too, but existing code could be using it. The parent of 1 is 0 and the parent of 0 is itself.

jshell> ProcessHandle.of(0).get().info()
$1 ==> [user: Optional[root], startTime: Optional[2026-04-19T12:05:59.162Z]]

RogerRiggs · 2026-04-21T17:19:14Z

ProcessHandle.of(0) returns a real handle on Mac, but not on Linux or Windows. We could disallow its creation on Mac too, but existing code could be using it. The parent of 1 is 0 and the parent of 0 is itself.

ok, pid 0 is the kernel on MacOS.
The anomaly is caused by the overload of 0 when calling native to return all processes.
The invariant should be that the stream returned from getDescendants() does not return a ProcessHandle for the pid itself. But I suppose that is a different bug. The current bug would not occur if the requested pid was ignored.

Michael-Mc-Mahon · 2026-04-23T12:13:39Z

ProcessHandle.of(0) returns a real handle on Mac, but not on Linux or Windows. We could disallow its creation on Mac too, but existing code could be using it. The parent of 1 is 0 and the parent of 0 is itself.

ok, pid 0 is the kernel on MacOS. The anomaly is caused by the overload of 0 when calling native to return all processes. The invariant should be that the stream returned from getDescendants() does not return a ProcessHandle for the pid itself. But I suppose that is a different bug. The current bug would not occur if the requested pid was ignored.

Yes. While you can argue it is reasonable that ProcessHandle.of(0).get().descendants() should return all processes, it's interesting that ProcessHandle.of(0).get().children() also returns all processes, due to that overloaded meaning of 0 in the native code. But, it should only return the handle for pid 1.

We could change the native code to use -1 as the special value to return all processes, but in the end it would be new behavior and wouldn't return anything useful.

I'm okay with just disallowing the creation of ProcessHandle.of(0) on Mac.

Michael-Mc-Mahon · 2026-04-24T09:55:33Z

Any other comments on the fix?

RogerRiggs · 2026-04-24T13:50:53Z

I looked at a refactoring to change the sentinel value to -1 and avoid 0.
Also added some MacOSX tests for pid 0.
See draft PR: #30923
Use it as you see fit or I can convert it to a non-draft PR.

Michael-Mc-Mahon · 2026-04-24T16:19:19Z

I looked at a refactoring to change the sentinel value to -1 and avoid 0. Also added some MacOSX tests for pid 0. See draft PR: #30923 Use it as you see fit or I can convert it to a non-draft PR.

Okay, I'll take a look.

fix

2c62796

remove imports not needed

c746c05

openjdk Bot added nio nio-dev@openjdk.org core-libs core-libs-dev@openjdk.org labels Apr 16, 2026

openjdk Bot added the rfr Pull request is ready for review label Apr 16, 2026

remove files

13b9507

openjdk Bot removed the nio nio-dev@openjdk.org label Apr 16, 2026

Merge branch 'master' into pidzero

69a4874

RogerRiggs reviewed Apr 16, 2026

View reviewed changes

Marcono1234 reviewed Apr 16, 2026

View reviewed changes

updated impl and test

557922d

AlanBateman reviewed Apr 16, 2026

View reviewed changes

turbanoff reviewed Apr 17, 2026

View reviewed changes

Comment thread src/java.base/share/classes/java/lang/ProcessHandleImpl.java Outdated

Update src/java.base/share/classes/java/lang/ProcessHandleImpl.java

ce462da

Co-authored-by: Andrey Turbanov <turbanoff@gmail.com>

Merge branch 'master' into pidzero

5f978aa

Michael-Mc-Mahon added 2 commits April 23, 2026 13:57

update

f50fb96

typo

3d447ab


		import org.junit.jupiter.api.Test;

		/*

Conversation

Michael-Mc-Mahon commented Apr 16, 2026 • edited by openjdk Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Progress

Issue

Reviewing

Uh oh!

bridgekeeper Bot commented Apr 16, 2026

Uh oh!

openjdk Bot commented Apr 16, 2026

Uh oh!

openjdk Bot commented Apr 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mlbridge Bot commented Apr 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Webrevs

Uh oh!

AlanBateman commented Apr 16, 2026

Uh oh!

openjdk Bot commented Apr 16, 2026

Uh oh!

RogerRiggs Apr 16, 2026

Choose a reason for hiding this comment

Uh oh!

Marcono1234 Apr 16, 2026

Choose a reason for hiding this comment

Uh oh!

Marcono1234 Apr 16, 2026

Choose a reason for hiding this comment

Uh oh!

Michael-Mc-Mahon Apr 16, 2026

Choose a reason for hiding this comment

Uh oh!

AlanBateman Apr 16, 2026

Choose a reason for hiding this comment

Uh oh!

Michael-Mc-Mahon Apr 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

RogerRiggs commented Apr 18, 2026

Uh oh!

Michael-Mc-Mahon commented Apr 20, 2026

Uh oh!

RogerRiggs commented Apr 21, 2026

Uh oh!

Michael-Mc-Mahon commented Apr 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

RogerRiggs commented Apr 21, 2026

Uh oh!

Michael-Mc-Mahon commented Apr 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Michael-Mc-Mahon commented Apr 24, 2026

Uh oh!

RogerRiggs commented Apr 24, 2026

Uh oh!

Michael-Mc-Mahon commented Apr 24, 2026

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

5 participants

Michael-Mc-Mahon commented Apr 16, 2026 •

edited by openjdk Bot

Loading

openjdk Bot commented Apr 16, 2026 •

edited

Loading

mlbridge Bot commented Apr 16, 2026 •

edited

Loading

Michael-Mc-Mahon Apr 17, 2026 •

edited

Loading

Michael-Mc-Mahon commented Apr 21, 2026 •

edited

Loading

Michael-Mc-Mahon commented Apr 23, 2026 •

edited

Loading