Bug 452899 - Event Dispatch Thread hangs.
Event Dispatch Thread hangs.
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: java-1.7.0-icedtea (Show other bugs)
8
All Linux
low Severity medium
: ---
: ---
Assigned To: Lillian Angel
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-06-25 13:48 EDT by szakrewsky
Modified: 2009-01-09 01:38 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-09 01:38:13 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Source for example code. (5.95 KB, application/x-gzip)
2008-06-25 13:48 EDT, szakrewsky
no flags Details

  None (edit)
Description szakrewsky 2008-06-25 13:48:30 EDT
Description of problem:

The Event Dispatch Thread Hangs when showing a modal dialog while running a
SwingWorker Thread.

Sorry if I waste your time if the code is wrong, however I am pretty sure I am
doing everything correctly.  I have included the code which causes the problem.
 My test case just puts the SwingWorker to sleep
but the problem occurs if I do something real, like connect to a database, etc.
 Also I have tried little different variations of the logic calling
setVisible(true)/(false) in different places and the same problem occurs.

It seems to work with Sun JDK.


Version-Release number of selected component (if applicable):

[szakrews@tuxtel ~]$ java -version
java version "1.7.0"
IcedTea Runtime Environment (build 1.7.0-b21)
IcedTea Client VM (build 1.7.0-b21, mixed mode)


How reproducible:

Every couple times.

tar -xzf <attached tar.gz>
cd ./test
javac TestClass2
java TestClass2

eventually it will hang.  If it doesn't try again.

You don't have to wait for the program to finish either.
The program runs the Dialog 10 times but it never works or fails in the middle
it will either work or fail from the first dialog displayed.

I have included a thread dump.  That is about the most informative information
I can get.  Neither tracing nor writing a custom ThreadQueue or Drawing Manager
to trace events produces any helpful information.


Actual results:

The JProccessBar won't move, and the SwingWorker finishes but the done() method
is never run.  The PROGRAM is not hung however because if I close the dialog
then it will continue.

Expected results:

The JProccessBar should always move and the SwingWorker should always run the
done() method.

Additional info:

java thread dump after freeze, taken with kill -s SIGQUIT <pid>

2008-06-25 12:25:50
Full thread dump IcedTea Client VM (1.7.0-b21 mixed mode):

"DestroyJavaVM" prio=10 tid=0x938afc00 nid=0x1419 waiting on condition
[0x00000000..0x0018a074]
   java.lang.Thread.State: RUNNABLE

"AWT-EventQueue-0" prio=10 tid=0x938ae400 nid=0x1429 in Object.wait()
[0x07f96000..0x07f96f04]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x96748f80> (a java.awt.EventQueue)
        at java.lang.Object.wait(Object.java:503)
        at java.awt.EventQueue.getNextEvent(EventQueue.java:485)
        - locked <0x96748f80> (a java.awt.EventQueue)
        at
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:248)
        at
java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:201)
        at
java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:195)
        at java.awt.Dialog$1.run(Dialog.java:1073)
        at java.awt.Dialog$3.run(Dialog.java:1127)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.awt.Dialog.show(Dialog.java:1125)
        at java.awt.Component.show(Component.java:1456)
        at java.awt.Component.setVisible(Component.java:1408)
        at java.awt.Window.setVisible(Window.java:871)
        at java.awt.Dialog.setVisible(Dialog.java:1012)
        at net.xtel.production.WaitDialog.showWaitDialog(WaitDialog.java:72)
        at net.xtel.production.WaitDialog.showWaitDialog(WaitDialog.java:102)
        at TestClass2.showWait(TestClass2.java:79)
        at TestClass2.createAndShowGUI(TestClass2.java:126)
        at TestClass2.access$0(TestClass2.java:114)
        at TestClass2$3.run(TestClass2.java:138)
        at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:227)
        at java.awt.EventQueue.dispatchEvent(EventQueue.java:603)
        at
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:276)
        at
java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:201)
        at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:191)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:186)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:178)
        at java.awt.EventDispatchThread.run(EventDispatchThread.java:139)

"AWT-Shutdown" prio=10 tid=0x938ad000 nid=0x1428 in Object.wait()
[0x03ea7000..0x03ea7f84]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x96749268> (a java.lang.Object)
        at java.lang.Object.wait(Object.java:503)
        at sun.awt.AWTAutoShutdown.run(AWTAutoShutdown.java:281)
        - locked <0x96749268> (a java.lang.Object)
        at java.lang.Thread.run(Thread.java:675)

"AWT-XAWT" daemon prio=10 tid=0x938a8400 nid=0x1423 runnable
[0x02ccc000..0x02ccd104]
   java.lang.Thread.State: RUNNABLE
        at sun.awt.X11.XToolkit.waitForEvents(Native Method)
        at sun.awt.X11.XToolkit.run(XToolkit.java:550)
        at sun.awt.X11.XToolkit.run(XToolkit.java:525)
        at java.lang.Thread.run(Thread.java:675)

"Java2D Disposer" daemon prio=10 tid=0x93854000 nid=0x1421 in Object.wait()
[0x07aea000..0x07aead84]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x966e7010> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:134)
        - locked <0x966e7010> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:150)
        at sun.java2d.Disposer.run(Disposer.java:143)
        at java.lang.Thread.run(Thread.java:675)

"Low Memory Detector" daemon prio=10 tid=0x93c15000 nid=0x141f runnable
[0x00000000..0x00000000]
   java.lang.Thread.State: RUNNABLE

"CompilerThread0" daemon prio=10 tid=0x93c13400 nid=0x141e waiting on condition
[0x00000000..0x03a8a954]
   java.lang.Thread.State: RUNNABLE

"Signal Dispatcher" daemon prio=10 tid=0x93c11c00 nid=0x141d waiting on
condition [0x00000000..0x00000000]
   java.lang.Thread.State: RUNNABLE

"Finalizer" daemon prio=10 tid=0x095e7000 nid=0x141c in Object.wait()
[0x005d2000..0x005d3004]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x966e71d8> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:134)
        - locked <0x966e71d8> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:150)
        at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:177)

"Reference Handler" daemon prio=10 tid=0x095e2400 nid=0x141b in Object.wait()
[0x00581000..0x00582084]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x966e7260> (a java.lang.ref.Reference$Lock)
        at java.lang.Object.wait(Object.java:503)
        at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:134)
        - locked <0x966e7260> (a java.lang.ref.Reference$Lock)

"VM Thread" prio=10 tid=0x095dec00 nid=0x141a runnable 

"VM Periodic Task Thread" prio=10 tid=0x93c17400 nid=0x1420 waiting on condition 

JNI global references: 836

Heap
 def new generation   total 960K, used 152K [0x93f40000, 0x94040000, 0x966a0000)
  eden space 896K,   9% used [0x93f40000, 0x93f56148, 0x94020000)
  from space 64K, 100% used [0x94020000, 0x94030000, 0x94030000)
  to   space 64K,   0% used [0x94030000, 0x94030000, 0x94040000)
 tenured generation   total 4096K, used 1088K [0x966a0000, 0x96aa0000, 0xb3f40000)
   the space 4096K,  26% used [0x966a0000, 0x967b01b0, 0x967b0200, 0x96aa0000)
 compacting perm gen  total 12288K, used 9169K [0xb3f40000, 0xb4b40000, 0xb7f40000)
   the space 12288K,  74% used [0xb3f40000, 0xb4834740, 0xb4834800, 0xb4b40000)
No shared spaces configured.
Comment 1 szakrewsky 2008-06-25 13:48:30 EDT
Created attachment 310286 [details]
Source for example code.
Comment 2 Bug Zapper 2008-11-26 05:55:29 EST
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 3 Bug Zapper 2009-01-09 01:38:13 EST
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.