On 29.1.2015 14:58, Daniel Fuchs wrote:
Hi Jaroslav,
The only thread state that this test is waiting on seems to be
Thread.State.BLOCKED - which makes me wonder if you could add a
method:
String waitForBlockedState(Thread t) throws InterruptedException {
long tid = lt.getId();
ThreadInfo ti;
while ( (ti = mbean.getThreadInfo(tid)).getThreadState() !=
Thread.State.BLOCKED) {
Thread.sleep(3);
}
return ti.getLockName();
}
Retrieving ThreadInfo is a rather extensive operation involving security
checks and as such might interfere with the test. It would require a
thorough analysis to prove that it wouldn't interfere with the counters
the test checks in any situation.
-JB-
Would that be feasible - or would it have side effects on what the
test is testing?
best regards,
-- daniel
On 29/01/15 14:03, Jaroslav Bachorik wrote:
Please, review the following test change.
Issue : https://bugs.openjdk.java.net/browse/JDK-8071641
Webrev: http://cr.openjdk.java.net/~jbachorik/8071641/webrev.00/
The test fails very intermittently with NPE. This seems to be caused by
a data race between Thread.getStatus() and ThreadMXBean.getThreadInfo()
- thread state is reported as BLOCKED but the ThreadInfo still contains
a stale information (lockname == null).
The solution would be re-retrieving the ThreadInfo until it reflects the
actual thread state.
-JB-
