JDK-6379235 : (thread) ThreadGroup accounting mistake possible with failure of Thread.start()
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 6
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2006-01-31
  • Updated: 2011-05-18
  • Resolved: 2011-05-18
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 7
7 b21Fixed
Related Reports
Relates :  
JDK-6988618 - JCK test setDaemon0101 hangs on specific machine
Relates :  
JDK-6378434 - (thread) IllegalThreadStateException invoking Thread.start after getting OOME (jdk5.0)
Relates :  
JDK-7013961 - Threads attached via JNI attach prevent daemon ThreadGroups from being destroyed
Description
Eliminating the "duplicate state" variable Thread.started creates the scenario in which an OOM from the VM thrown out by Thread.start followed by invoking start a second time can result in duplicate Thread references being present in ThreadGroup (e.g. making ThreadGroup.activeCount return a too-high value).
Comments
EVALUATION Summary of changes to fix this bug: 1) Thread.start first adds the thread to the thread group 2) calls start0 to create the native thread and associated resources 3) if successfull decrements thread groups unStartedThreads count else removes it from the group.
30-08-2007
EVALUATION This was puzzled over and there is hope for a proper solution, but the right course to follow isn't really understood yet, so the status is moved back to "cause known."
08-06-2006
EVALUATION A bug deserving attention!
31-01-2006
SUGGESTED FIX Either ThreadGroup.add could be enhanced to avoid duplicate Thread instances or else Thread.start could catch an exception thrown by the VM (via start0), fix up the group, then rethrow the exception. (For the case where the exception is thrown by ThreadGroup.add (or Arrays.copyOf) the right thing happens already.)
31-01-2006