JDK-8219197 : ThreadGroup.enumerate() may return wrong value
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 11,12,13
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2019-02-14
  • Updated: 2019-04-03
  • Resolved: 2019-03-13
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 13
13 b13Fixed
Related Reports
Relates :  
JDK-8220516 - ThreadGroup::destroy may leave the thread group in an inconsistent state.
Description
A DESCRIPTION OF THE PROBLEM :
ThreadGroup.enumerate() sometimes returns a small value (eg. 1) when in fact there are many threads in the system. The problem is caused because the method

private int enumerate(Thread list[], int n, boolean recurse)

Sometimes returns 0 , when it should return n

See https://hg.openjdk.java.net/jdk/jdk11/file/76072a077ee1/src/java.base/share/classes/java/lang/ThreadGroup.java#l428

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
No steps. I think the description is clear


FREQUENCY : occasionally
Comments
https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-March/058950.html
12-03-2019
From what I can see there may be the possibility that the subgroups cannot be destroyed if they contain active threads - but the parent group will have been marked as destroyed by that time. So if you call enumerate() on the parent group, you will get 0 even though some of its subgroups might still have active threads. Which is arguably a bug in ThreadGroup::destroy(). Note: This is not the main issue reported by this bug - and since fixing it is more complex then this will be tracked by JDK-8220516.
12-03-2019
Ah - yes - that too. It's a race condition between enumerate and destroy.
26-02-2019
Additional Information from submitter: The semantic of this function is, it receives an array and an integer 'n' that indicates the first free position into the array to store information. When this function returns it has to report the next free position into the array. It should never return '0'. If no information was stored into the array, it should return the same 'n'
26-02-2019
From submitter: It seems to affect all versions since at least Java 1.1
21-02-2019