[ping] Re: RFR 8077327: ThreadStackTrace.java throws exception: BlockedThread expected to have BLOCKED but got RUNNABLE
serguei.spitsyn at oracle.com
serguei.spitsyn at oracle.com
Tue Apr 14 12:37:36 UTC 2015
On 4/14/15 12:38 AM, Daniel Fuchs wrote:
> Hi Jaroslav,
>
> Shouldn't you also wait for the blockedThread to be blocked on
> lockA at around line 252?
> (I mean - using Utils.waitForThreadState(blockedThread, State.BLOCKED))
I guess, it is about these lines:
255 Utils.checkThreadState(blockedThread,
Thread.State.BLOCKED);
256 checkStack(blockedThread, blockedStack, bsDepth);
The implementation of the Utils.checkThreadState() from Utils.java:
public static void checkThreadState(Thread t, Thread.State expected) {
waitForThreadState(t, expected); <=== It does the call to the
waitForThreadState
Thread.State state = tm.getThreadInfo(t.getId()).getThreadState();
if (state == null) {
throw new RuntimeException(t.getName() + " expected to have " +
expected + " but got null.");
}
if (state != expected) {
t.dumpStack();
throw new RuntimeException(t.getName() +
" expected to have " + expected + " but got " + state);
}
}
Thanks,
Serguei
>
> best regards,
>
> -- daniel
>
> On 4/13/15 10:07 AM, Jaroslav Bachorik wrote:
>> On 9.4.2015 20:11, Jaroslav Bachorik wrote:
>>> Please, review the following test change
>>>
>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8077327
>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8077327/webrev.00
>>>
>>> This fix is for an intermittent failure due to timing issues. The test
>>> is using an arbitrary waiting period to allow the tested thread to
>>> arrive to the requested state. Usually it works fine but under eg.
>>> heavy
>>> load this strategy will fail. The proposed solution is to explicitly
>>> check for the test thread arriving to the requested state instead of
>>> waiting eg. 10ms.
>>>
>>> I also took the liberty of removing the custom Semaphore implementation
>>> and replacing its usage with java.util.concurrent.Phaser
>>>
>>> Thanks,
>>>
>>> -JB-
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20150414/64ca1b26/attachment.html>
More information about the serviceability-dev
mailing list