From philip.race at oracle.com Fri Jan 13 18:19:29 2017 From: philip.race at oracle.com (Phil Race) Date: Fri, 13 Jan 2017 10:19:29 -0800 Subject: RFR 8172765, closed/javax/sound/sampled/Clip/AppletAudioClip/SoundBug.java failed in headless system In-Reply-To: References: Message-ID: <8b886e01-3082-1952-9e9c-3f7851162f1e@oracle.com> I deleted core-libs since I can't for the life of me think what this has to do with that list Anyway, "+1" -phil. On 01/13/2017 09:57 AM, Felix Yang wrote: > Hi team, > please review the patch to mark following test as headful. It has > been failing in Mach 5 for several runs > > Bug: https://bugs.openjdk.java.net/browse/JDK-8172765 > > Thanks, > Felix > > Patch: > > diff -r 2ca43b220611 > javax/sound/sampled/Clip/AppletAudioClip/SoundBug.java > --- a/javax/sound/sampled/Clip/AppletAudioClip/SoundBug.javaFri Jan 13 > 01:36:12 2017 +0000 > +++ b/javax/sound/sampled/Clip/AppletAudioClip/SoundBug.javaFri Jan 13 > 09:34:46 2017 -0800 > @@ -11,7 +11,7 @@ > * @test > * @bug 4181910 > * @summary AudioClip incompatibility > - * @key closed-binary > + * @key closed-binary headful > */ > public class SoundBug extends Frame { > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anton.litvinov at oracle.com Wed Jan 18 17:22:45 2017 From: anton.litvinov at oracle.com (Anton Litvinov) Date: Wed, 18 Jan 2017 20:22:45 +0300 Subject: [9] Review request for 8168751: Two "Direct Clip" threads are created to play the same "AudioClip" object, what makes clip sound corrupted Message-ID: <103da6ce-e0b6-e2fa-385c-b31923acb6fc@oracle.com> Hello, Could you please review the following fix for the bug. Bug: https://bugs.openjdk.java.net/browse/JDK-8168751 Webrev: http://cr.openjdk.java.net/~alitvinov/8168751/jdk9/webrev.00 The bug consists in the fact that after many repetitive sequential calls to the methods "loop()", "stop()" on the same instance of "java.applet.AudioClip" at some moment two threads with the name "Direct Clip", which play this "AudioClip" instance, are created and start existing in parallel, what makes the being played clip sound as corrupted. "Direct Clip" thread is represented by the instance variable "com.sun.media.sound.DirectAudioDevice.DirectClip.thread", is created in the method "com.sun.media.sound.DirectAudioDevice.DirectClip.open()" and is stopped by assigning "null" value to "DirectClip.thread" instance variable in the method "com.sun.media.sound.DirectAudioDevice.DirectClip.implClose()". THE DEFINED ROOT CAUSES OF THE BUG: 1. The fact that "DirectClip.thread" instance variable is not thread-safe. There is a possibility that null value assigned to it in one thread through the former mentioned "DirectClip.implClose()" method does not become visible for the running "Direct Clip" thread in the method "DirectClip.run()". 2. In the method "DirectClip.run()" not taking into account the fact that a new "Direct Clip" thread could have already been started and assigned to "DirectClip.thread" instance variable after the call to "DirectClip.implClose()", by the moment when "DirectClip.thread" value is checked for null in "DirectClip.run()" method, or by the moment when the previous "Direct Clip" thread is awakened and continues execution after the following code block in "DirectClip.run()" from the file "jdk/src/java.desktop/share/classes/com/sun/media/sound/DirectAudioDevice.java". 1354 try { 1355 lock.wait(); 1356 } catch(InterruptedException ie) {} THE SOLUTION: The solution is based on correction of the listed above 2 root causes of the bug. Thank you, Anton -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergey.bylokhov at oracle.com Wed Jan 18 21:34:22 2017 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 19 Jan 2017 00:34:22 +0300 Subject: [9] Review request for 8168751: Two "Direct Clip" threads are created to play the same "AudioClip" object, what makes clip sound corrupted In-Reply-To: <103da6ce-e0b6-e2fa-385c-b31923acb6fc@oracle.com> References: <103da6ce-e0b6-e2fa-385c-b31923acb6fc@oracle.com> Message-ID: Hi, Anton. Probably some other fields in the DirectClip should be marked as volatile? For example loopStartFrame/loopEndFrame/ are used in the run() but assigned in the setLoopPoints () w/o any synchronization?(the same setFramePosition +newFramePosition/clipBytePosition) > > Hello, > > Could you please review the following fix for the bug. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8168751 > Webrev: http://cr.openjdk.java.net/~alitvinov/8168751/jdk9/webrev.00 > > The bug consists in the fact that after many repetitive sequential calls to the methods "loop()", "stop()" on the same instance of "java.applet.AudioClip" at some moment two threads with the name "Direct Clip", which play this "AudioClip" instance, are created and start existing in parallel, what makes the being played clip sound as corrupted. > > "Direct Clip" thread is represented by the instance variable "com.sun.media.sound.DirectAudioDevice.DirectClip.thread", is created in the method "com.sun.media.sound.DirectAudioDevice.DirectClip.open()" and is stopped by assigning "null" value to "DirectClip.thread" instance variable in the method "com.sun.media.sound.DirectAudioDevice.DirectClip.implClose()". > > THE DEFINED ROOT CAUSES OF THE BUG: > > 1. The fact that "DirectClip.thread" instance variable is not thread-safe. There is a possibility that null value assigned to it in one thread through the former mentioned "DirectClip.implClose()" method does not become visible for the running "Direct Clip" thread in the method "DirectClip.run()". > > 2. In the method "DirectClip.run()" not taking into account the fact that a new "Direct Clip" thread could have already been started and assigned to "DirectClip.thread" instance variable after the call to "DirectClip.implClose()", by the moment when "DirectClip.thread" value is checked for null in "DirectClip.run()" method, or by the moment when the previous "Direct Clip" thread is awakened and continues execution after the following code block in "DirectClip.run()" from the file "jdk/src/java.desktop/share/classes/com/sun/media/sound/DirectAudioDevice.java". > > 1354 try { > 1355 lock.wait(); > > 1356 } catch(InterruptedException ie) {} > > THE SOLUTION: > The solution is based on correction of the listed above 2 root causes of the bug. > > Thank you, > Anton From anton.litvinov at oracle.com Fri Jan 20 13:35:21 2017 From: anton.litvinov at oracle.com (Anton Litvinov) Date: Fri, 20 Jan 2017 16:35:21 +0300 Subject: [9] Review request for 8168751: Two "Direct Clip" threads are created to play the same "AudioClip" object, what makes clip sound corrupted In-Reply-To: References: <103da6ce-e0b6-e2fa-385c-b31923acb6fc@oracle.com> Message-ID: <346d134c-e7ec-4b2b-4158-72ad90ccb17c@oracle.com> Hello Sergey, Thank you for review of this fix. Yes, I agree that 4 fields of "DirectAudioDevice.DirectClip" class which you specified ("loopStartFrame", "loopEndFrame", "newFramePosition", "clipBytePosition") are also not thread-safe and should be marked with "volatile" modifier, though they are not directly related to this bug. The second version of the fix, which addresses your remark, was created. In the second version of the fix "volatile" modifier was added to the next 8 fields of "DirectClip" class, all of which are accessed both from "DirectClip.run()" method and other methods of this class: "audioData", "frameSize", "m_lengthInFrames", "loopCount", "clipBytePosition", "newFramePosition", "loopStartFrame", "loopEndFrame". Could you please review the second version of the fix. Webrev: http://cr.openjdk.java.net/~alitvinov/8168751/jdk9/webrev.01 Thank you, Anton On 1/19/2017 12:34 AM, Sergey Bylokhov wrote: > Hi, Anton. > Probably some other fields in the DirectClip should be marked as volatile? For example loopStartFrame/loopEndFrame/ are used in the run() but assigned in the setLoopPoints > () w/o any synchronization?(the same setFramePosition +newFramePosition/clipBytePosition) > >> Hello, >> >> Could you please review the following fix for the bug. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8168751 >> Webrev: http://cr.openjdk.java.net/~alitvinov/8168751/jdk9/webrev.00 >> >> The bug consists in the fact that after many repetitive sequential calls to the methods "loop()", "stop()" on the same instance of "java.applet.AudioClip" at some moment two threads with the name "Direct Clip", which play this "AudioClip" instance, are created and start existing in parallel, what makes the being played clip sound as corrupted. >> >> "Direct Clip" thread is represented by the instance variable "com.sun.media.sound.DirectAudioDevice.DirectClip.thread", is created in the method "com.sun.media.sound.DirectAudioDevice.DirectClip.open()" and is stopped by assigning "null" value to "DirectClip.thread" instance variable in the method "com.sun.media.sound.DirectAudioDevice.DirectClip.implClose()". >> >> THE DEFINED ROOT CAUSES OF THE BUG: >> >> 1. The fact that "DirectClip.thread" instance variable is not thread-safe. There is a possibility that null value assigned to it in one thread through the former mentioned "DirectClip.implClose()" method does not become visible for the running "Direct Clip" thread in the method "DirectClip.run()". >> >> 2. In the method "DirectClip.run()" not taking into account the fact that a new "Direct Clip" thread could have already been started and assigned to "DirectClip.thread" instance variable after the call to "DirectClip.implClose()", by the moment when "DirectClip.thread" value is checked for null in "DirectClip.run()" method, or by the moment when the previous "Direct Clip" thread is awakened and continues execution after the following code block in "DirectClip.run()" from the file "jdk/src/java.desktop/share/classes/com/sun/media/sound/DirectAudioDevice.java". >> >> 1354 try { >> 1355 lock.wait(); >> >> 1356 } catch(InterruptedException ie) {} >> >> THE SOLUTION: >> The solution is based on correction of the listed above 2 root causes of the bug. >> >> Thank you, >> Anton From alexey.menkov at oracle.com Mon Jan 23 09:34:51 2017 From: alexey.menkov at oracle.com (Alex Menkov) Date: Mon, 23 Jan 2017 12:34:51 +0300 Subject: [9] Review request for 8168751: Two "Direct Clip" threads are created to play the same "AudioClip" object, what makes clip sound corrupted In-Reply-To: <346d134c-e7ec-4b2b-4158-72ad90ccb17c@oracle.com> References: <103da6ce-e0b6-e2fa-385c-b31923acb6fc@oracle.com> <346d134c-e7ec-4b2b-4158-72ad90ccb17c@oracle.com> Message-ID: Looks good to me. --alex On 20.01.2017 16:35, Anton Litvinov wrote: > Hello Sergey, > > Thank you for review of this fix. Yes, I agree that 4 fields of > "DirectAudioDevice.DirectClip" class which you specified > ("loopStartFrame", "loopEndFrame", "newFramePosition", > "clipBytePosition") are also not thread-safe and should be marked with > "volatile" modifier, though they are not directly related to this bug. > > The second version of the fix, which addresses your remark, was created. > In the second version of the fix "volatile" modifier was added to the > next 8 fields of "DirectClip" class, all of which are accessed both from > "DirectClip.run()" method and other methods of this class: "audioData", > "frameSize", "m_lengthInFrames", "loopCount", "clipBytePosition", > "newFramePosition", "loopStartFrame", "loopEndFrame". Could you please > review the second version of the fix. > > Webrev: http://cr.openjdk.java.net/~alitvinov/8168751/jdk9/webrev.01 > > Thank you, > Anton > > On 1/19/2017 12:34 AM, Sergey Bylokhov wrote: >> Hi, Anton. >> Probably some other fields in the DirectClip should be marked as >> volatile? For example loopStartFrame/loopEndFrame/ are used in the >> run() but assigned in the setLoopPoints >> () w/o any synchronization?(the same setFramePosition >> +newFramePosition/clipBytePosition) >> >>> Hello, >>> >>> Could you please review the following fix for the bug. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8168751 >>> Webrev: http://cr.openjdk.java.net/~alitvinov/8168751/jdk9/webrev.00 >>> >>> The bug consists in the fact that after many repetitive sequential >>> calls to the methods "loop()", "stop()" on the same instance of >>> "java.applet.AudioClip" at some moment two threads with the name >>> "Direct Clip", which play this "AudioClip" instance, are created and >>> start existing in parallel, what makes the being played clip sound as >>> corrupted. >>> >>> "Direct Clip" thread is represented by the instance variable >>> "com.sun.media.sound.DirectAudioDevice.DirectClip.thread", is created >>> in the method >>> "com.sun.media.sound.DirectAudioDevice.DirectClip.open()" and is >>> stopped by assigning "null" value to "DirectClip.thread" instance >>> variable in the method >>> "com.sun.media.sound.DirectAudioDevice.DirectClip.implClose()". >>> >>> THE DEFINED ROOT CAUSES OF THE BUG: >>> >>> 1. The fact that "DirectClip.thread" instance variable is not >>> thread-safe. There is a possibility that null value assigned to it in >>> one thread through the former mentioned "DirectClip.implClose()" >>> method does not become visible for the running "Direct Clip" thread >>> in the method "DirectClip.run()". >>> >>> 2. In the method "DirectClip.run()" not taking into account the fact >>> that a new "Direct Clip" thread could have already been started and >>> assigned to "DirectClip.thread" instance variable after the call to >>> "DirectClip.implClose()", by the moment when "DirectClip.thread" >>> value is checked for null in "DirectClip.run()" method, or by the >>> moment when the previous "Direct Clip" thread is awakened and >>> continues execution after the following code block in >>> "DirectClip.run()" from the file >>> "jdk/src/java.desktop/share/classes/com/sun/media/sound/DirectAudioDevice.java". >>> >>> >>> 1354 try { >>> 1355 lock.wait(); >>> >>> 1356 } catch(InterruptedException ie) {} >>> >>> THE SOLUTION: >>> The solution is based on correction of the listed above 2 root causes >>> of the bug. >>> >>> Thank you, >>> Anton > From sergey.bylokhov at oracle.com Mon Jan 23 16:12:39 2017 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 23 Jan 2017 19:12:39 +0300 Subject: [9] Review request for 8168751: Two "Direct Clip" threads are created to play the same "AudioClip" object, what makes clip sound corrupted In-Reply-To: References: <103da6ce-e0b6-e2fa-385c-b31923acb6fc@oracle.com> <346d134c-e7ec-4b2b-4158-72ad90ccb17c@oracle.com> Message-ID: <56411BB2-1651-43D7-871A-01A7A8FD0ACF@oracle.com> +1 > > Looks good to me. > > --alex > > On 20.01.2017 16:35, Anton Litvinov wrote: >> Hello Sergey, >> >> Thank you for review of this fix. Yes, I agree that 4 fields of >> "DirectAudioDevice.DirectClip" class which you specified >> ("loopStartFrame", "loopEndFrame", "newFramePosition", >> "clipBytePosition") are also not thread-safe and should be marked with >> "volatile" modifier, though they are not directly related to this bug. >> >> The second version of the fix, which addresses your remark, was created. >> In the second version of the fix "volatile" modifier was added to the >> next 8 fields of "DirectClip" class, all of which are accessed both from >> "DirectClip.run()" method and other methods of this class: "audioData", >> "frameSize", "m_lengthInFrames", "loopCount", "clipBytePosition", >> "newFramePosition", "loopStartFrame", "loopEndFrame". Could you please >> review the second version of the fix. >> >> Webrev: http://cr.openjdk.java.net/~alitvinov/8168751/jdk9/webrev.01 >> >> Thank you, >> Anton >> >> On 1/19/2017 12:34 AM, Sergey Bylokhov wrote: >>> Hi, Anton. >>> Probably some other fields in the DirectClip should be marked as >>> volatile? For example loopStartFrame/loopEndFrame/ are used in the >>> run() but assigned in the setLoopPoints >>> () w/o any synchronization?(the same setFramePosition >>> +newFramePosition/clipBytePosition) >>> >>>> Hello, >>>> >>>> Could you please review the following fix for the bug. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8168751 >>>> Webrev: http://cr.openjdk.java.net/~alitvinov/8168751/jdk9/webrev.00 >>>> >>>> The bug consists in the fact that after many repetitive sequential >>>> calls to the methods "loop()", "stop()" on the same instance of >>>> "java.applet.AudioClip" at some moment two threads with the name >>>> "Direct Clip", which play this "AudioClip" instance, are created and >>>> start existing in parallel, what makes the being played clip sound as >>>> corrupted. >>>> >>>> "Direct Clip" thread is represented by the instance variable >>>> "com.sun.media.sound.DirectAudioDevice.DirectClip.thread", is created >>>> in the method >>>> "com.sun.media.sound.DirectAudioDevice.DirectClip.open()" and is >>>> stopped by assigning "null" value to "DirectClip.thread" instance >>>> variable in the method >>>> "com.sun.media.sound.DirectAudioDevice.DirectClip.implClose()". >>>> >>>> THE DEFINED ROOT CAUSES OF THE BUG: >>>> >>>> 1. The fact that "DirectClip.thread" instance variable is not >>>> thread-safe. There is a possibility that null value assigned to it in >>>> one thread through the former mentioned "DirectClip.implClose()" >>>> method does not become visible for the running "Direct Clip" thread >>>> in the method "DirectClip.run()". >>>> >>>> 2. In the method "DirectClip.run()" not taking into account the fact >>>> that a new "Direct Clip" thread could have already been started and >>>> assigned to "DirectClip.thread" instance variable after the call to >>>> "DirectClip.implClose()", by the moment when "DirectClip.thread" >>>> value is checked for null in "DirectClip.run()" method, or by the >>>> moment when the previous "Direct Clip" thread is awakened and >>>> continues execution after the following code block in >>>> "DirectClip.run()" from the file >>>> "jdk/src/java.desktop/share/classes/com/sun/media/sound/DirectAudioDevice.java". >>>> >>>> >>>> 1354 try { >>>> 1355 lock.wait(); >>>> >>>> 1356 } catch(InterruptedException ie) {} >>>> >>>> THE SOLUTION: >>>> The solution is based on correction of the listed above 2 root causes >>>> of the bug. >>>> >>>> Thank you, >>>> Anton >>