-
Bug
-
Resolution: Fixed
-
P2
-
1.0, 1.0.2
-
1.2alpha
-
generic, sparc
-
generic, solaris_2.4
-
Not verified
There are a bunch of methods in class Thread that test tid->PrivateInfo and
then go off to use it, without synchronizing the access. It is theoretically possible
(with details varying by platform) that the thread that was just alive (its
tid->PrivateInfo was nonzero) could be killed before using PrivateInfo. If
that happened, PrivateInfo would be zeroed and the the system would probably
crash. This has not actually been observed.
A quick list of affected methods of class Thread are (approximately):
Thread.getPriority
Thread.setPriority
Thread.suspend
Thread.resume
Thread.isAlive should also be considered for synchronization and correctness,
although it doesn't suffer from the same race condition.
I don't think that Thread.start and Thread.stop are affected -- they are
synchronized in the C code.
then go off to use it, without synchronizing the access. It is theoretically possible
(with details varying by platform) that the thread that was just alive (its
tid->PrivateInfo was nonzero) could be killed before using PrivateInfo. If
that happened, PrivateInfo would be zeroed and the the system would probably
crash. This has not actually been observed.
A quick list of affected methods of class Thread are (approximately):
Thread.getPriority
Thread.setPriority
Thread.suspend
Thread.resume
Thread.isAlive should also be considered for synchronization and correctness,
although it doesn't suffer from the same race condition.
I don't think that Thread.start and Thread.stop are affected -- they are
synchronized in the C code.
- duplicates
-
JDK-4009941 sys_thread_t could go away before SCHED_LOCK is obtained
- Closed