JDK-8153534 : Intermittent hang in GSTMedia.gstDispose
  • Type: Bug
  • Component: javafx
  • Sub-Component: media
  • Affected Version: 8u51,9
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2016-04-05
  • Updated: 2017-09-07
  • Resolved: 2016-05-10
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 8 JDK 9
8u102Fixed 9Fixed
Related Reports
Relates :  
JDK-8154375 - Deadlock in FLV demux
Relates :  
JDK-8158109 - Compilation error in FX media native code with VS 2010
Description
We are occasionally seeing intermittent hangs (possibly due to deadlock) in the native GSTMedia.gstDispose method, which causes the JavaFX application to hang. The test case is an application that loads and then disposes various web pages using WebView, some of which have media.
Comments
The test requires Internet access or special configuration. Also, failure is intermittent, so "ursqe-hard-test-intermittent"
24-05-2016
No issues related to the fix in the recent FX Media nightly results. OK to take it in PSU16_03
16-05-2016
http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/5a05735abf8f
10-05-2016
Approved to backport to 8u-dev for 8u112.
10-05-2016
Looks fine, +1
10-05-2016
Looks good to me. I see no more hangs in my testing. It would be good for Dave D to review, too. +1
09-05-2016
Please review the following: Reviewers: kcr, ddehaven http://cr.openjdk.java.net/~almatvee/8153534/webrev.9.0/ - Fixed two deadlocks in gstqueue by preventing pausing task if pad is not connected and by forcing loop to exit when transition between PAUSE->READY. Code that stops loop between READY->NULL is probably not needed, but I decided to keep it just in case if loop will be restarted between READY and NULL state. - dshowrapper will send EOS from separate thread instead of DShow thread. This prevents deadlock when we trying to start, stop, create or destroy DShow graph while DShow main thread is waiting to deliver EOS inside GStreamer. Basically, we cannot block DShow main thread since it is shared by all graphs in same application and it is used to create, destroy, start or stop graph and sometimes for EOS depending on some conditions. - Fixed race conditions for delivering and freeing output buffer. - During pad going to inactive state we will decommit DShow buffer allocator to unblock chain function which can wait for new buffers. http://cr.openjdk.java.net/~almatvee/8153534/webrev.8u.0/ Mostly same as 9, except: - Fixed locking issue in gstbaseparse. Should prevent potential deadlock for MP3, WAV or AIFF. Was discovered during investigation of this issue. Not needed for 9 due to difference in GStreamer code. - gstqueue code is same in logic, but uses older GStreamer APIs. - dshowwrapper_activatepush is used instead of dshowwrapper_activatemode due to API differences.
07-05-2016