Details

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

      Description


      Name: fb126949 Date: 08/26/2003

      Found one Java-level deadlock:
      =============================
      "AWT-EventQueue-0":
         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 com.sun.media.sound.H
      eadspaceMixer),
         which is held by "AWT-EventQueue-0"

      Java stack information for the threads listed above:
      ===================================================
      "AWT-EventQueue-0":
               at com.sun.media.sound.EventDispatcher.autoClosingClipOpened(EventDispatcher.java:447)
               - waiting to lock <0x105128f8> (a java.util.ArrayList)
               at com.sun.media.sound.MixerClip.open(MixerClip.java:166)
               - locked <0x1050da70> (a com.sun.media.sound.HeadspaceMixer)
               at com.sun.media.sound.JavaSoundAudioClip.startImpl(JavaSoundAudioClip.java:143)
               - locked <0x10520310> (a com.sun.media.sound.JavaSoundAudioClip)
               at com.sun.media.sound.JavaSoundAudioClip.play(JavaSoundAudioClip.java:120)
               - locked <0x10520310> (a com.sun.media.sound.JavaSoundAudioClip)
               at sun.applet.AppletAudioClip.play(AppletAudioClip.java:194)
               - locked <0x10516ae8> (a sun.applet.AppletAudioClip)
               at Wall.processBallMovement(Wall.java:140)
               at Ball.notifyListeners(Ball.java:76)
               at Ball.actionPerformed(Ball.java:57)
               at javax.swing.Timer.fireActionPerformed(Timer.java:271)
               at javax.swing.Timer$DoPostEvent.run(Timer.java:201)
               at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:178)
               at java.awt.EventQueue.dispatchEvent(EventQueue.java:454)
               at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:208)
               at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:157)
               at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:151)

               at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:143)

               at java.awt.EventDispatchThread.run(EventDispatchThread.java:104) "Java Sound event dispatcher":
               at com.sun.media.sound.AbstractDataLine.close(AbstractDataLine.java:414)

               - waiting to lock <0x1050da70> (a com.sun.media.sound.HeadspaceMixer)
               at com.sun.media.sound.EventDispatcher.closeAutoClosingClips(EventDispatcher.java:430)
               - locked <0x105128f8> (a java.util.ArrayList)
               at com.sun.media.sound.EventDispatcher.dispatchEvents(EventDispatcher.java:339)
               at com.sun.media.sound.EventDispatcher.run(EventDispatcher.java:374)
               at java.lang.Thread.run(Thread.java:534)


      > 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:
      > clip.open()
      > which calls MixerClip.open(), 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 AudioClip.play()) 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.



      ======================================================================

        Attachments

          Issue Links

            Activity

              People

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

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Imported:
                  Indexed: