• Subcomponent:
    • Resolved In Build:
    • CPU:
    • OS:


      Name: fb126949 Date: 08/26/2003

      Found one Java-level deadlock:
         waiting to lock monitor 0x008101cc (object 0x105128f8, a java.util.ArrayList),

         which is held by "Java Sound event dispatcher"
      "Java Sound event dispatcher":
         waiting to lock monitor 0x008101ac (object 0x1050da70, a
         which is held by "AWT-EventQueue-0"

      Java stack information for the threads listed above:
               - waiting to lock <0x105128f8> (a java.util.ArrayList)
               - locked <0x1050da70> (a
               - locked <0x10520310> (a
               - locked <0x10520310> (a
               - locked <0x10516ae8> (a sun.applet.AppletAudioClip)
               at Wall.processBallMovement(
               at Ball.notifyListeners(
               at Ball.actionPerformed(
               at javax.swing.Timer.fireActionPerformed(
               at javax.swing.Timer$
               at java.awt.event.InvocationEvent.dispatch(
               at java.awt.EventQueue.dispatchEvent(
               at java.awt.EventDispatchThread.pumpOneEventForHierarchy(
               at java.awt.EventDispatchThread.pumpEventsForHierarchy(
               at java.awt.EventDispatchThread.pumpEvents(

               at java.awt.EventDispatchThread.pumpEvents(

               at "Java Sound event dispatcher":

               - waiting to lock <0x1050da70> (a
               - locked <0x105128f8> (a java.util.ArrayList)

      > I don't have a test case yet, but I can see the deadlock in the code,
      > from tracing the info in the trace below.
      > JavaSoundAudioClip does this:
      > which calls, which does this:
      > synchronized (mixer) {
      > getEventDispatcher().autoClosingClipOpened(this);
      > }
      > and EventDispatcher().autoClosingClipOpened(this) does this:
      > synchronized (autoClosingClips) {
      > ...
      > }
      > where audioClips is an ArrayList() object.
      > Meanwhile, on the Event Dispatching thread, we call:
      > closeAutoClosingClips(), which does this:
      > synchronized (audioClosingClips) {
      > clip.close();
      > where close() is in AbstractDataLine:
      > public void close() {
      > synchronized (mixer) {
      > ...
      > and voila, DEADLOCK.
      > The first thread above grabs the mixer and then tries to lock
      > the audioClips object. Meanwhile, the dispatch thread grabs the
      > audioClips object and then tries to lock the mixer.
      > The fix must involve somehow guaranteeing that these threads cannot
      > be doing these things at the same time or that the objects they
      > are locking (mixer and audioClips) cannot be locked out of order.
      > I wonder if the call to:
      > getEventDispatcher().autoClosingClipOpened(this);
      > above is correct? That is, do we really want to execute this
      > dispatcher method on the current thread, or do we want to tell the
      > dispatcher to execute this call on the dispatcher thread? If we
      > put it on the dispatcher thread, then this deadlock is avoided because
      > the dispatcher thread cannot deadlock with itself.

      > I realized that my app was actually doing rendering (and thus
      > calling from 2 distinct threads. I tweaked
      > the SoundDeadlock app to do the same thing (issue plays from
      > 2 different threads), but I still haven't seen the deadlock there.
      > Maybe there's just a really small window where this deadlock can
      > occur and it's just a (small) random chance that it'll crop up.



          Issue Links



              • Assignee:
                fbomerssunw Florian Bomers (Inactive)
                fbomerssunw Florian Bomers (Inactive)
              • Votes:
                0 Vote for this issue
                0 Start watching this issue


                • Created: