JDK-8113716 : HelloMedia audio is not terminated
  • Type: Bug
  • Component: javafx
  • Sub-Component: media
  • Affected Version: fx2.0
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2011-05-31
  • Updated: 2015-06-16
  • Resolved: 2011-08-11
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.
Other
fx2.0Fixed
Related Reports
Blocks :  
JDK-8113904 - Need Toolkit shutdown hook to clean up resources, etc.
Duplicate :  
JDK-8112781 - FossilGame doesn't finish after clicking exit button
Duplicate :  
JDK-8113474 - Mac app will not quit when media is playing
Relates :  
JDK-8114590 - Native threads should attach as daemons
Relates :  
JDK-8113687 - MediaSystemTest benchmarks throws "IllegalStateException: The view has already been closed" with j2d pipeline
Description
build 170

Audio is not terminated after the window is closed.  This is also seen in VideoCube and HelloAlpha samples.

jstack output:
2011-05-31 15:16:01
Full thread dump Java HotSpot(TM) Client VM (17.1-b03 mixed mode, sharing):

"Timer-0" daemon prio=6 tid=0x02bedc00 nid=0x784 in Object.wait() [0x045ef000]
   java.lang.Thread.State: TIMED_WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x22de06f8> (a java.util.TaskQueue)
        at java.util.TimerThread.mainLoop(Timer.java:509)
        - locked <0x22de06f8> (a java.util.TaskQueue)
        at java.util.TimerThread.run(Timer.java:462)

"Media Resource Disposer" daemon prio=6 tid=0x03061400 nid=0x1648 in Object.wait
() [0x0441f000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x22de07a8> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:118)
        - locked <0x22de07a8> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:134)
        at com.sun.media.jfxmediaimpl.MediaDisposer.disposerLoop(MediaDisposer.j
ava:111)
        at com.sun.media.jfxmediaimpl.MediaDisposer.access$100(MediaDisposer.jav
a:20)
        at com.sun.media.jfxmediaimpl.MediaDisposer$1.run(MediaDisposer.java:90)

        at java.lang.Thread.run(Thread.java:662)

"Thread-8" prio=6 tid=0x03069000 nid=0x10fc runnable [0x00000000]
   java.lang.Thread.State: RUNNABLE

"Thread-7" prio=6 tid=0x03068800 nid=0x1010 runnable [0x00000000]
   java.lang.Thread.State: RUNNABLE

"DestroyJavaVM" prio=6 tid=0x002b6c00 nid=0x124 waiting on condition [0x00000000
]
   java.lang.Thread.State: RUNNABLE

"Thread-6" prio=6 tid=0x0305a400 nid=0xa40 runnable [0x00000000]
   java.lang.Thread.State: RUNNABLE

"Thread-5" prio=6 tid=0x0306a800 nid=0xfa0 runnable [0x00000000]
   java.lang.Thread.State: RUNNABLE

"JFXMedia Player EventQueueThread" daemon prio=6 tid=0x03050c00 nid=0xe20 waitin
g on condition [0x0378f000]
   java.lang.Thread.State: WAITING (parking)
        at sun.misc.Unsafe.park(Native Method)
        - parking to wait for  <0x22de0a98> (a java.util.concurrent.locks.Abstra
ctQueuedSynchronizer$ConditionObject)
        at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject
.await(AbstractQueuedSynchronizer.java:1987)
        at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.jav
a:399)
        at com.sun.media.jfxmediaimpl.NativeMediaPlayer$EventQueueThread.run(Nat
iveMediaPlayer.java:471)

"Disposer" daemon prio=10 tid=0x03047400 nid=0x11ac in Object.wait() [0x0333f000
]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x22de0b88> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:118)
        - locked <0x22de0b88> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:134)
        at com.sun.glass.utils.Disposer.run(Disposer.java:64)
        at java.lang.Thread.run(Thread.java:662)

"Thread-2" daemon prio=6 tid=0x02be6c00 nid=0xe8c runnable [0x00000000]
   java.lang.Thread.State: RUNNABLE

"Low Memory Detector" daemon prio=6 tid=0x02b2d000 nid=0x125c runnable [0x000000
00]
   java.lang.Thread.State: RUNNABLE

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

"Attach Listener" daemon prio=10 tid=0x02b25400 nid=0x1728 waiting on condition
[0x00000000]
   java.lang.Thread.State: RUNNABLE

"Signal Dispatcher" daemon prio=10 tid=0x02b23c00 nid=0xb5c runnable [0x00000000
]
   java.lang.Thread.State: RUNNABLE

"Finalizer" daemon prio=8 tid=0x02b20400 nid=0x11ec in Object.wait() [0x02cef000
]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x22de10a8> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:118)
        - locked <0x22de10a8> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:134)
        at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)

"Reference Handler" daemon prio=10 tid=0x02b1b800 nid=0xb7c in Object.wait() [0x
02c9f000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x22de07e0> (a java.lang.ref.Reference$Lock)
        at java.lang.Object.wait(Object.java:485)
        at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116)
        - locked <0x22de07e0> (a java.lang.ref.Reference$Lock)

"VM Thread" prio=10 tid=0x02b1a000 nid=0x10d8 runnable

"VM Periodic Task Thread" prio=10 tid=0x02b37800 nid=0x13d8 waiting on condition


JNI global references: 1187
Comments
Never mind: I did not see the previous comment from Alexander K.
29-08-2011
Do any of the clips used in VideoCube have an audio track? I downloaded one and VLC did not play audio from it either.
29-08-2011
VideoCube has no audio.
29-08-2011
There is writen about VideoCube and HelloAlpha in the description. But in Win7, FXb42 I hear audio in HelloAlpha, and i don't hear any audio/sound/voice in VideoCube. Is this the problem arising from here, or I have to open a new bug? Also, how to effectively check this issue, to close it? In HelloAlpha sound finishes on exit from application. [two weeks for answer]
29-08-2011
Re-resolved in http://jfxsrc.us.oracle.com/javafx/presidio/scrum/media/runtime/rev/18a241011618.
11-08-2011
Reopening this issue, because this change causing large memory leak. When running MediaLeakTest from RT-12934 MediaPlayer instances will not GC and thus we will run out of memory quickly. I think it happens, because ShutdownHook holds hard reference to MediaPlayer.
11-08-2011
Fixed by registering shutdown hook in MediaPlayer: http://jfxsrc.us.oracle.com/javafx/presidio/scrum/media/runtime/rev/ad3ae0bcb8a7.
10-08-2011
Based on the discussion I am removing this as a deferral candidate.
27-07-2011
I disagree with this issue being a deferral candidate. It is almost certainly a side effect of an insufficient shutdown / application lifecycle architecture.
26-07-2011
Note that the fix for RT-14594 masks the problem described in this issue. To reproduce this issue the change in RT-14594 will need to be reverted.
27-06-2011
Using jvisualvm heap dumps, it appears as if a hard reference to the MediaView is still held after the window is closed. As the MediaView holds a hard reference to the javafx.scene.media.MediaPlayer, the playback engine is not terminated as this only happens when the implementation layer player is disposed which only occurs in response to all references to the FX layer player being enqueued.
14-06-2011
Changing AttachCurrentThread() to AttachCurrentThreadAsDaemon() in the native layer in fact makes this problem go away. There is probably some other reason however so this change should not be made prior to further investigation. Eventually however we should probably always attach as daemon threads.
10-06-2011
If in SwingMediaPlayer.java line 174 is commented out, the media including audio stops playing when the window is closed although the app does not exit. If however line 172 is commented out, the window closes but audio continues. Therefore this looks like it is a problem with the player not being properly disposed. This could be related to the MediaDIsposer which was added not that long ago, or it could be in the FX layer. 170 public void windowClosed(WindowEvent e) { 171 if (player != null) { 172 player.dispose(); 173 } 174 System.exit(0); 175 }
10-06-2011
Media does not create any threads in Java either in javafx.scene.media or in com.sun.media.jfxmedia*. One or more native threads is however attached in the code which sends events up to Java. A reference to the JNIEnv appears to be cached in a http://developer.gnome.org/glib/stable/glib-Threads.html#GStaticPrivate. It should first be verified whether any references of this nature are being held and preventing the JVM from exiting.
10-06-2011
In the stack trace listed in the description, the following non-daemon threads are preventing the JVM from exiting. I verified the same 4 threads are present in the latest (b31) build. These are most likely native media threads. "Thread-8" prio=6 tid=0x03069000 nid=0x10fc runnable [0x00000000] java.lang.Thread.State: RUNNABLE "Thread-7" prio=6 tid=0x03068800 nid=0x1010 runnable [0x00000000] java.lang.Thread.State: RUNNABLE "Thread-6" prio=6 tid=0x0305a400 nid=0xa40 runnable [0x00000000] java.lang.Thread.State: RUNNABLE "Thread-5" prio=6 tid=0x0306a800 nid=0xfa0 runnable [0x00000000] java.lang.Thread.State: RUNNABLE
10-06-2011
This is still present on Windows in presidio-b31.
08-06-2011
Glass no longer calls System.exit() explicitly. FX now relies on JVM to terminate the app when only daemon threads are running. The jstack output from the Description shows that there's several non-daemon threads running. Until those are terminated, the JVM won't exit.
07-06-2011
Changing affected components and reassigning based on the process of elimination detailed in my previous comment, i.e., testing using a full forest built with the media repository and media-specific part of the runtime repository at revision b30 and the glass repository and the non-media part of the runtime repository at revision b29.
04-06-2011
I don't believe that this is a media problem. I did the following in a native Windows clone of the media-scrum full forest (which at present is identical to presidio-b30 except for the tag): $ cd glass $ hg revert -r presidio-b29 --all $ cd ../runtime $ hg revert -r presidio-b29 --all $ hg revert javafx-ui-desktop $ hg revert -r ffb784c98f2c javafx-sg-common/src/com/sun/javafx/sg/PGMediaView.java javafx-sg-prism/src/com/sun/javafx/sg/prism/NGMediaView.java javafx-sg-swing/src/com/sun/scenario/scenegraph/SGMediaView.java toys/HelloWorld/src/helloworld/HelloMediaFPS.java The presidio-media-scrum changeset ffb784c98f2c is detailed here http://jfxsrc.sfbay.sun.com/javafx/presidio/scrum/media/runtime/rev/ffb784c98f2c and is post-b30. So in summary, the forest is in effect b30 except for glass and the non-javafx-ui-desktop part of runtime which are both b29. When this forest is built, the failure to terminate audio no longer occurs. Therefore the problem is not in the media component per se, but is rather exposed by the media component.
04-06-2011
Reproducible on Windows as indicated in the report, but not on Mac OS X.
01-06-2011
Also, WebLauncher does not terminate after window closed
01-06-2011