JDK-7049111 : java/lang/Thread/ThreadStateTest.java with JDK7 b143
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 7
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 2011-05-27
  • Updated: 2011-12-22
  • Resolved: 2011-05-31
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.
Other
tbd_minorResolved
Related Reports
Duplicate :  
JDK-7021010 - (thread) TEST_BUG java/lang/Thread/ThreadStateTest.java fails intermittently
Description
The log is:

java.lang.RuntimeException: MyThread expected to have TIMED_WAITING but got WAITING
	at ThreadStateTest.checkThreadState(ThreadStateTest.java:119)
	at ThreadStateTest.main(ThreadStateTest.java:75)
	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:601)
	at com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94)
	at java.lang.Thread.run(Thread.java:722)

Reproducible on vmsqe-p4-05, linux-i586 using VM options '-client -Xcomp -XX:+StartAttachListener -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode' after 61 iteration.
Comments
EVALUATION There are timing issues in this test. It is most likely that this is a duplicate of CR 7021010.
30-05-2011
PUBLIC COMMENTS The Solaris x86 problem may be completely unrelated. I instrumented the loop: while(!semaphore.hasQueuedThreads()) { try { Thread.sleep(20); } catch (InterruptedException xx) {} } and found that we are not looping: the sleep is not returning. This is a virtual Solaris environment so the problem may be related to virtual timer support (sleep is implemented via poll in Solaris). Updated to add: this is unrelated to the problem reported in this CR. It seems to be an issue with the poll syscall underlying Thread.sleep in a virtualized Solaris environment.
29-05-2011
PUBLIC COMMENTS I tried to reproduce on Solaris x86 and got a hang: bus2001029 /java/east/u2/dh198349/tests > java -Xcomp -client ThreadStateTest Checking thread state NEW ^\2011-05-29 00:59:00 Full thread dump Java HotSpot(TM) Client VM (21.0-b13 compiled mode): "MyThread" prio=3 tid=0x08299400 nid=0xa waiting on condition [0xe7a6a000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0xe7e64218> (a java.util.concurrent.Semaphore$NonfairSync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:964) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1282) at java.util.concurrent.Semaphore.acquireUninterruptibly(Semaphore.java:340) at ThreadStateTest$ThreadExecutionSynchronizer.stopOrGo(ThreadStateTest.java:361) at ThreadStateTest$ThreadExecutionSynchronizer.signal(ThreadStateTest.java:383) at ThreadStateTest$MyThread.run(ThreadStateTest.java:161) "main" prio=3 tid=0x08065800 nid=0x2 waiting on condition [0xfe22e000] java.lang.Thread.State: TIMED_WAITING (sleeping) at java.lang.Thread.sleep(Native Method) at ThreadStateTest$ThreadExecutionSynchronizer.stopOrGo(ThreadStateTest.java:367) at ThreadStateTest$ThreadExecutionSynchronizer.waitForSignal(ThreadStateTest.java:379) at ThreadStateTest$MyThread.waitUntilStarted(ThreadStateTest.java:254) at ThreadStateTest.main(ThreadStateTest.java:63) The main thread should be seeing semaphore.hasQueuedThreads() and end it's sleep loop, but it is not. It is unclear whether this is another occurrence of the occasional Semaphore problem that can be seen on Solaris - 7011859 - though that was only reproducible on sparc.
29-05-2011