RFR 8071641: java/lang/management/ThreadMXBean/SynchronizationStatistics.java intermittently failed with NPE

[Daniel Fuchs]

On 29/01/15 16:21, Jaroslav Bachorik wrote:
> 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.

Well then - I guess that what you have is good to go...

-- daniel

>
> -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-
>>
>