JDK-6944188 : ThreadMXBean/ThreadStateTest.java fails intermittently
  • Type: Bug
  • Component: core-svc
  • Sub-Component: java.lang.management
  • Affected Version: 7
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2010-04-15
  • Updated: 2014-04-07
  • Resolved: 2013-11-06
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8 Other
8 b117Fixed port-stage-ppc-aixFixed
Related Reports
Relates :  
JDK-7021010 - (thread) TEST_BUG java/lang/Thread/ThreadStateTest.java fails intermittently
Relates :  
JDK-8022208 - Intermittent test failures in java/lang/Thread/ThreadStateTest.java
Relates :  
JDK-8028565 - Remove java/lang/management/ThreadMXBean/ThreadStateTest.java from ProblemList.txt
Description
TESTFAIL:java/lang/management/ThreadMXBean/ThreadStateTest.java

I was doing JDK7-B87 baseline testing on my VMware WinXP client
and the following SDK/JDK test failed:

    java/lang/management/ThreadMXBean/ThreadStateTest.java

Here is a snippet from the .jtr file:

----------System.out:(6/202)----------
Waiting myThread to go blocked.
  myThread is going to block.
Waiting myThread to go waiting.
  myThread is going to wait.
Waiting myThread to go timed waiting.
  myThread is going to timed wait.
----------System.err:(18/1126)----------
java version "1.7.0-ea"
Java(TM) SE Runtime Environment (build 1.7.0-ea-b87)
Java HotSpot(TM) Server VM (build 18.0-b01, compiled mode)

java.lang.RuntimeException: MyThread expected to be blocked on lock [ThreadStateTest$Lock@c8f6f8] but got null.
        at ThreadStateTest.checkLockInfo(ThreadStateTest.java:177)
        at ThreadStateTest.main(ThreadStateTest.java:91)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:613)
        at com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94)
        at java.lang.Thread.run(Thread.java:717)

JavaTest Message: Test threw exception: java.lang.RuntimeException: MyThread expected to be blocked on lock [ThreadStateTest$Lock@c8f6f8] but got null.
JavaTest Message: shutting down test

STATUS:Failed.`main' threw exception: java.lang.RuntimeException: MyThread expected to be blocked on lock [ThreadStateTest$Lock@c8f6f8] but got null.
result: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: MyThread expected to be blocked on lock [ThreadStateTest$Lock@c8f6f8] but got null.


test result: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: MyThread expected to be blocked on lock [ThreadStateTest$Lock@c8f6f8] but got null.
Comments
Shanliang - I have refactored ThreadStateTest as part of JDK-8022208 that should resolve this bug too. I'll take this bug and fix it in the same changeset.
05-11-2013
You can set an insanely huge waiting time - the waiting will be terminated either by the test itself after checking for the lock or the whole test will timeout when error occurs. That will significantly lower the test timing sensitivity.
23-10-2013
About the failure of: ---------- java.lang.RuntimeException: MyThread expected to be blocked on lock [ThreadStateTest$Lock@1ba2f45] but got null. at ThreadStateTest.checkLockInfo(ThreadStateTest.java:177) at ThreadStateTest.main(ThreadStateTest.java:91) ---------- I believe the problem is from Line 285: globalLock.wait(10000); 10 seconds must be enough in usual case, but it could be still too short if testing on a very busy machine. One simple solution is to set longer waiting time for myThread.goTimedWaiting(), but we can never be sure to have a right value. Another solution is that MyThread will wait only short time, but check a flag to see whether to repeat waiting or to return. I did a test by by setting 10ms instead of 10s, the test failed always.
12-09-2013