JDK-6741489 : java/util/concurrent/FutureTask/BlockingTaskExecutor.java fails with java.lang.Error: Executor stuck
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util.concurrent
  • Affected Version: 6,7
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic,windows_2003
  • CPU: generic,x86
  • Submitted: 2008-08-26
  • Updated: 2014-08-26
  • Resolved: 2011-03-21
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
8Resolved
Related Reports
Duplicate :  
JDK-6535709 - interrupt of wait()ing thread isn't triggering InterruptedException - test intwait3
Relates :  
JDK-6712206 - java/util/concurrent tests fail in Xcomp with assertion in HS13b02
Relates :  
JDK-6498581 - ThreadInterruptTest3 produces wrong output on Windows
Description
java/util/concurrent/FutureTask/BlockingTaskExecutor.java fails on windows-i586 with 
the following error message:
----------System.out:(3/128)----------
....................................................................................................
Passed = 0, failed = 1

----------System.err:(23/1366)----------
java.lang.Error: Executor stuck
	at BlockingTaskExecutor.test(BlockingTaskExecutor.java:75)
	at BlockingTaskExecutor.realMain(BlockingTaskExecutor.java:43)
	at BlockingTaskExecutor.main(BlockingTaskExecutor.java:160)
	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:623)
	at com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94)
	at java.lang.Thread.run(Thread.java:674)
java.lang.AssertionError: Some tests failed
	at BlockingTaskExecutor.main(BlockingTaskExecutor.java:162)
	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:623)
	at com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94)
	at java.lang.Thread.run(Thread.java:674)

JavaTest Message: Test threw exception: java.lang.AssertionError: Some tests failed
JavaTest Message: shutting down test

STATUS:Failed.`main' threw exception: java.lang.AssertionError: Some tests failed
result: Failed. Execution failed: `main' threw exception: java.lang.AssertionError: Some tests failed


test result: Failed. Execution failed: `main' threw exception: java.lang.AssertionError: Some tests failed
Cannot reproduce with S:/jdk/re/7/promoted/all/b33/binaries/windows-i586
Update: somehow it reproduced with b33 too on 7th time.
So it seems to be quite intermittent.
Comments
EVALUATION This has the same underlying cause as 6535709. There is a race in os::is_interrupted on Windows that can cause an interrupt to get "lost". This can lead to wait() never returning (as here) or returning but failing to throw InterruptedException (as per 6535709 testcase).
20-03-2011
EVALUATION I've been able to reproduce this issue on Windows 2003 (about one in a few hundred runs). Reproduced with both client and server. Without Xcomp. And even with Xint. So it looks most likely to be a runtime issue. Here is a jstack from the hung process that shows why it is failing (line numbers may be a little out of sync due to instrumentation): Exception: ----------- java.lang.Error: Executor stuck at BlockingTaskExecutor.test(BlockingTaskExecutor.java:75) at BlockingTaskExecutor.realMain(BlockingTaskExecutor.java:43) at BlockingTaskExecutor.main(BlockingTaskExecutor.java:166) Passed = 0, failed = 1 Exception in thread "main" java.lang.AssertionError: Some tests failed at BlockingTaskExecutor.main(BlockingTaskExecutor.java:168) jstack ------- .... "pool-26-thread-1" prio=6 tid=0x0000000006847000 nid=0x3a8 in Object.wait() [0x0 00000000673f000] java.lang.Thread.State: WAITING (on object monitor) JavaThread state: _thread_blocked Thread: 0x0000000006847000 [0x3a8] State: _at_safepoint _has_called_back 0 _at_ poll_safepoint 0 JavaThread state: _thread_blocked at java.lang.Object.wait(Native Method) - waiting on <0x00000000f55ddff0> (a BlockingTaskExecutor$BlockingTask) at java.lang.Object.wait(Object.java:504) at BlockingTaskExecutor$BlockingTask.call(BlockingTaskExecutor.java:135) - locked <0x00000000f55ddff0> (a BlockingTaskExecutor$BlockingTask) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor. java:1111) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor .java:603) at java.lang.Thread.run(Thread.java:722) "Thread-25" prio=6 tid=0x00000000058fd800 nid=0x918 waiting on condition [0x0000 00000663f000] java.lang.Thread.State: WAITING (parking) JavaThread state: _thread_blocked Thread: 0x00000000058fd800 [0x918] State: _at_safepoint _has_called_back 0 _at_ poll_safepoint 0 JavaThread state: _thread_blocked at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000000f59f07d8> (a java.util.concurrent.Futu reTask$Sync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInt errupt(AbstractQueuedSynchronizer.java:834) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared Interruptibly(AbstractQueuedSynchronizer.java:994) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedIn terruptibly(AbstractQueuedSynchronizer.java:1303) at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:248) at java.util.concurrent.FutureTask.get(FutureTask.java:111) at java.util.concurrent.AbstractExecutorService.invokeAll(AbstractExecut orService.java:243) at BlockingTaskExecutor$1.run(BlockingTaskExecutor.java:61) ... In the test executor.awaitTermination() waits for up to 5 seconds before throwing "Executor Stuck", this should be sufficient time. The test starts two BlockingTasks that will be started before the pool is shutdownNow. These tasks will not terminate themselves, instead they will wait() to be interrupted by the pool during shutdown. The jstack shows the thread invoking invokeAll, Thread-25, is blocked waiting for one of the pools tasks to complete ( or be terminated ), and we can also see one of the pools threads, pool-26-thread-1, that is blocked during execution of BlockingTask.call. The BlockingTask is blocked in an Object wait, which is what the test wants to do. The expectation is that this task will be receive an interrupt when the pool is being shutdown. With some simple instrumentation it can be shown that the thread running the BlockingTask never receives an interrupt, and also that the pools interruptWorkers does invoke thread.interrupt on the BlockingTask thread. So where's the interrupt going? Is this a duplication of CR 6535709, or CR 6498581? These CR's seem to indicate that it is possible for interrupts to be "lost" on some Windows platforms.
14-03-2011