[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