-
Bug
-
Resolution: Fixed
-
P4
-
7
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2217230 | 7u4 | Denis Fokin | P3 | Closed | Fixed | b06 |
FULL PRODUCT VERSION :
java version "1.7.0"
Java(TM) SE Runtime Environment (build 1.7.0-b147)
Java HotSpot(TM) Server VM (build 21.0-b17, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
Linux localhost.localdomain 2.6.40.3-0.fc15.i686 #1 SMP Tue Aug 16 04:24:09 UTC 2011 i686 i686 i386 GNU/Linux
A DESCRIPTION OF THE PROBLEM :
Disposing an AppContext can lead to a spinning EventDispatchThread.
When calling AppContext.dispose() it first calls Thread.interrupt(), and after some time Thread.stop() for Threads that didn't terminate on interrupt (quick enough).
If the EventDispatchThread belonging to an AppContext didn't terminate timely, and Thread.stop() is called for this Thread an endless loop can occur.
In EventQueue.getNextEvent condition.await() is called to wait for new events, which throws a ThreadDeath in the case Thread.stop() was called. However, because unlocking the monitor in the finally-statement also throws an Exception now, ThreadDeath is swollowed:
EventQueue.getNextEvent():
pushPopLock.lock();
try {
pushPopCond.await(); //Throws ThreadDeath
} finally {
pushPopLock.unlock(); //Now throws IllegalMonitorException, swollows ThreadDeath.
}
however, because the EventDispatchThread.pumpOneEventForFilters() requires catching ThreadDeath-Throwables to determine it shouls really stop (variable threadDeathCaught set to true), it never terminates. This was most likely caused by the switch from java-monitors to java.util.concurrent, as monitors don't throw an Exception if unlocking fails.
If there are still pending events in the EventQueue the thread starts spinning, because EventDispatchThread.pumpEventsForFilter(int id, Conditional cond, EventFilter filter) doesn't dispatch events if isInterrupted() returns true, and dispatching the EventQueue in run() fails (eq.detachDispatchThread(this)), because there are still events left which are not processed.
I intend to rovide patches for this through OpenJDK, just need a bug-ID.
REGRESSION. Last worked in version 7
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
hard to reproduce, we see it pccasionally on our caciocavallo-web server
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
EventDispatchThread should terminate as expected
ACTUAL -
EventDispatchThread runs in an endless loop, not dispatching events because the thread has been interrupted, and not terminating because there are still events in the queue.
REPRODUCIBILITY :
This bug can be reproduced occasionally.
java version "1.7.0"
Java(TM) SE Runtime Environment (build 1.7.0-b147)
Java HotSpot(TM) Server VM (build 21.0-b17, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
Linux localhost.localdomain 2.6.40.3-0.fc15.i686 #1 SMP Tue Aug 16 04:24:09 UTC 2011 i686 i686 i386 GNU/Linux
A DESCRIPTION OF THE PROBLEM :
Disposing an AppContext can lead to a spinning EventDispatchThread.
When calling AppContext.dispose() it first calls Thread.interrupt(), and after some time Thread.stop() for Threads that didn't terminate on interrupt (quick enough).
If the EventDispatchThread belonging to an AppContext didn't terminate timely, and Thread.stop() is called for this Thread an endless loop can occur.
In EventQueue.getNextEvent condition.await() is called to wait for new events, which throws a ThreadDeath in the case Thread.stop() was called. However, because unlocking the monitor in the finally-statement also throws an Exception now, ThreadDeath is swollowed:
EventQueue.getNextEvent():
pushPopLock.lock();
try {
pushPopCond.await(); //Throws ThreadDeath
} finally {
pushPopLock.unlock(); //Now throws IllegalMonitorException, swollows ThreadDeath.
}
however, because the EventDispatchThread.pumpOneEventForFilters() requires catching ThreadDeath-Throwables to determine it shouls really stop (variable threadDeathCaught set to true), it never terminates. This was most likely caused by the switch from java-monitors to java.util.concurrent, as monitors don't throw an Exception if unlocking fails.
If there are still pending events in the EventQueue the thread starts spinning, because EventDispatchThread.pumpEventsForFilter(int id, Conditional cond, EventFilter filter) doesn't dispatch events if isInterrupted() returns true, and dispatching the EventQueue in run() fails (eq.detachDispatchThread(this)), because there are still events left which are not processed.
I intend to rovide patches for this through OpenJDK, just need a bug-ID.
REGRESSION. Last worked in version 7
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
hard to reproduce, we see it pccasionally on our caciocavallo-web server
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
EventDispatchThread should terminate as expected
ACTUAL -
EventDispatchThread runs in an endless loop, not dispatching events because the thread has been interrupted, and not terminating because there are still events in the queue.
REPRODUCIBILITY :
This bug can be reproduced occasionally.
- backported by
-
JDK-2217230 Disposing an AppContext can lead to a spinning EventDispatchThread
-
- Closed
-
- relates to
-
JDK-7097333 Adding an EventQueue on the AWT queue prevents JVM from terminate on exit
-
- Open
-
-
JDK-4913324 Deadlock when using two event queues
-
- Resolved
-
-
JDK-7162144 Missing AWT thread in headless mode in 7u4 b06
-
- Closed
-
-
JDK-8059608 [macosx] closed/javax/swing/plaf/basic/AWTEventListenerLeak/AWTEventListenerLeak.java fails on MacOS
-
- Closed
-