JDK-4912588 : Thread Deadlock in Clip
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.sound
  • Affected Version: 5.0
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2003-08-26
  • Updated: 2003-10-13
  • Resolved: 2003-10-13
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
5.0 b24Fixed
Related Reports
Relates :  
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 com.sun.media.sound.H
   which is held by "AWT-EventQueue-0"

Java stack information for the threads listed above:
         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.


CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger tiger-beta FIXED IN: tiger-beta INTEGRATED IN: tiger-b24 tiger-beta

PUBLIC COMMENTS Thread Deadlock in Clip

EVALUATION ###@###.### 2003-08-26 Not yet investigated. Clip's stability is very important for many apps and applets. ###@###.### 2003-10-01 not reproduced by running, but verified the theoretical possibility. The Line base classes are a mess, so it is likely that there are still other bugs of this sort.