RFR 8071641: java/lang/management/ThreadMXBean/SynchronizationStatistics.java intermittently failed with NPE
Jaroslav Bachorik
jaroslav.bachorik at oracle.com
Fri Jan 30 09:34:26 UTC 2015
On 29.1.2015 16:59, shanliang wrote:
> Jaroslav Bachorik wrote:
>> On 29.1.2015 14:43, shanliang wrote:
>>> 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-
>>> 77 private static void waitForThreadState(Thread t, Thread.State
>>> state) throws InterruptedException {
>>> 78 while (!t.isInterrupted() && t.getState() != state) {
>>> 79 Thread.sleep(3);
>>> 80 }
>>> 81 }
>>> Better to throw an exception if t.isInterrupted()?
>>> Not sure when will happen t.isInterrupted(), but the method
>>> waitForThreadState tests it, so it is supposed to be possible to get it,
>>> when it is true then the testing method might return with a thread state
>>> different to the waited one.
>>
>> Yes, it might get to an undefined state. But given that the thread
>> would get interrupted only when the harness is timing out the test
>> this discrepancy would not actually matter - the test would fail with
>> timeout anyway.
> In this case it is useless to test t.isInterrupted() in waitForThreadState.
Probably it is. I will remove it before pushing then.
-JB-
>
> Shanliang
>>
>> -JB-
>>
>>>
>>> Shanliang
>>>
>>>
>>
>
More information about the serviceability-dev
mailing list