On Jan 10, 2006, at 5:52 PM, "charles chen" <email@hidden>
wrote:
Found one Java-level deadlock:
=============================
"Thread-39":
waiting to lock monitor 0x1802eb8 (object 0x4dc891b8, a
java.awt.EventQueue),
which is held by "AWT-AppKit"
"AWT-AppKit":
waiting to lock monitor 0x1802f90 (object 0x4dc891a0, a
sun.awt.PostEventQueue),
which is held by "Thread-39"
Java stack information for the threads listed above:
===================================================
"Thread-39":
at java.awt.EventQueue.postEventPrivate(EventQueue.java:211)
- waiting to lock <0x4dc891b8> (a java.awt.EventQueue)
at java.awt.EventQueue.postEvent(EventQueue.java:198)
at sun.awt.PostEventQueue.flush(SunToolkit.java:713)
- locked <0x4dc891a0> (a sun.awt.PostEventQueue)
at sun.awt.SunToolkit.flushPendingEvents(SunToolkit.java:350)
at java.awt.EventQueue.postEvent(EventQueue.java:197)
at java.awt.EventQueue.invokeLater(EventQueue.java:816)
at javax.swing.SwingUtilities.invokeLater(SwingUtilities.java:1170)
at digilabs.CalFrame.ReportProgress(CalFrame.java:5246)
at digilabs.io.ZipPackage.ZipFile(ZipPackage.java:199)
at digilabs.io.ZipPackage.DoArchive(ZipPackage.java:146)
at digilabs.io.ZipPackage.Archive(ZipPackage.java:122)
at digilabs.spool.JobUploader.CreatePackageSynch(JobUploader.java:969)
at digilabs.spool.JobUploader.DoCreatePackage(JobUploader.java:185)
at digilabs.spool.RemoteJobsSpooler.PrintingDone
(RemoteJobsSpooler.java:77)
at digilabs.spool.Spooler.DonePrinting(Spooler.java:241)
at digilabs.spool.Spooler$2.run(Spooler.java:221)
at java.lang.Thread.run(Thread.java:552)
"AWT-AppKit":
at sun.awt.PostEventQueue.postEvent(SunToolkit.java:726)
- waiting to lock <0x4dc891a0> (a sun.awt.PostEventQueue)
at sun.awt.SunToolkit.postEvent(SunToolkit.java:337)
at apple.awt.CToolkit.postEvent(CToolkit.java:1001)
at apple.awt.EventFactoryProxy.forwardEvent(EventFactoryProxy.java:63)
Classic deadlock caused by two threads acquiring two locks in
different order.
Thread-39 locks the sun.awt.PostEventQueue, then attempts to lock the
java.awt.EventQueue.
AWT-AppKit lockst the java.awt.EventQueue (although I do not see that
in the stack trace), then attempts to lock the sun.awt.PostEventQueue.
As you mentioned, the actual contents of the Runnable does not matter.
I don't suppose you're doing anything with Cocoa? I know that doing
some things from an ApplicationAdapter (handleQuit, etc.) may cause a
deadlock, but I don't remember the details.
This looks like a case of Sun vs Apple to me. That suggest that the
bug is in Apple's code. Please file a bug including this full thread
dump.
A temporary hack of a workaround is to lock the java.awt.EventQueue
before the call to invokeLater. Unfortunately, there is no guarantee
that the deadlock won't occur from other sources using invokeLater
(see the TimerQueue thread in your dump). Also, this workaround will
actually be prey to deadlocks if Apple fixes their code to acquire
the sun.awt.PostEventQueue first.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
