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

[Jaroslav Bachorik]

On 29.1.2015 16:44, Daniel Fuchs wrote:
> 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...

Yep, thanks. Testing the thread level counters has proved to be very 
tricky :(

-JB-

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