JDK-8207150 : Clip.isRunning() may return true after Clip.stop() was called
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.sound
  • Affected Version: 10,11,12
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2018-07-12
  • Updated: 2021-05-21
  • Resolved: 2018-09-08
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.
JDK 11 JDK 12 JDK 7 JDK 8
11.0.2Fixed 12 b14Fixed 7u211Fixed 8u202Fixed
Related Reports
Relates :  
JDK-8266421 - Deadlock in Sound System
Relates :  
JDK-8202264 - Race condition in AudioClip.loop()
Sub Tasks
JDK-8207210 :  
Problem list javax/sound/sampled/Clip/AutoCloseTimeCheck.java - Resolved
Description
java.lang.RuntimeException: Thread was found
	at AutoCloseTimeCheck.testBigDelay(AutoCloseTimeCheck.java:74)
	at AutoCloseTimeCheck.main(AutoCloseTimeCheck.java:58)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115)
	at java.base/java.lang.Thread.run(Thread.java:834)
Comments
Fix Request: It was escalated by customer and is a fix strongly associated with JDK-8202264. The bug exists because "autoclose" mechanics which was updated in JDK-8202264, cannot stop the thread of the clip, which is in "running" state. Fix has been backported to 8u and 7u also. jdk12 patch applies cleanly to 11u.
25-10-2018
This bug was found by the test added in JDK-8202264, this test checks this sequence: clip.loop(); clip.stop(); delay(20 sec); //check that Audio thread was stopped. The test fails because the thread was not stopped, the reason is that "autoclose" mechanics cannot stop the thread of the clip which is in "running" state. So the test can be simplified to: clip.loop(); clip.stop(); if(clip.isRunning()) BOOM(); The root cause description: The problem exists in our DirectAudioDevice implementation. Before we play the audio we have this check in write(): if (!isActive() && doIO) { setActive(true); setStarted(true); } And to stop the clip we have this: synchronized(lock) { // need to set doIO to false before notifying the // read/write thread, that's why isStartedRunning() // cannot be used doIO = false; lock.notifyAll(); } setActive(false); setStarted(false); Note that it is possible to get the next race. 1 write() -> if(doIO) is true 2 stop() -> doIO=false + setActive(false) + setStarted(false) 3 write() -> setActive(true) + setStarted(true)
04-08-2018
This is not a test bug. In JDK-8202264 the case, the audio thread was restarted too often, was fixed. And this new test found the opposite bug that the audio thread is not stopped when necessary.
03-08-2018
That sounds plausible. So othervm could cure it but since it has now been problem listed it should be less urgent.
13-07-2018
The test is run in agentVM mode so I'd have to suspect it could be impacted by what other tests in this area do.
13-07-2018