GNOME Bugzilla – Bug 766545
Pale Moon browser hang/deadlock on exit
Last modified: 2018-01-24 14:51:08 UTC
Created attachment 328036 [details] gst_liblist Hi. I'm using Firefox-based PaleMoon 26.2.2 x86 browser on Xubuntu 16.04 x64. Recently installed Gstreamer libs, all fine except on-exit deadlock with 100% load. With media.gstreamer.enabled=false no any issues (and no mp4 video), as before. Tried various combinations of good/bad/ugly plugin sets with same result. Steps to reproduce: open youtube, start playing HD video, close browser. More often occurs with vk.com videos (almost every time), less with YT. Attached gdb threads output and dpkg list of installed libs.
Created attachment 328037 [details] gst_threadsdump
Created attachment 328038 [details] gst_threadsdump
Could you install -dbg packages for GStreamer please, i.e. at least libgstreamer1.0-0-dbg gstreamer1.0-plugins-base-dbg gstreamer1.0-plugins-good-dbg ? Could you also provide a compressed GST_DEBUG=*:6 log from when the deadlock happens on exit?
Created attachment 328062 [details] gdb threads (2)
Created attachment 328063 [details] console debug output This is full console log from launch to exit, just ~12 secs. Enough to open-play-close-hang. Tested with vk.com's video since YT little harder to catch.
Mmmhh... You're decoding using gstreamer-vaapi. To be sure, can you uninstall gstreamer-vaapi, install gst-libav and check if the deadlock still happens?
(In reply to Víctor Manuel Jáquez Leal from comment #6) > Mmmhh... You're decoding using gstreamer-vaapi. > > To be sure, can you uninstall gstreamer-vaapi, install gst-libav and check > if the deadlock still happens? I've installed vaapi just yesterday to test whether hang with vaapi too, so it really shouldn't be a reason. One minute, I'll check.
Created attachment 328070 [details] gdb threads (3) No, still locking, as expected. Attaching new dump, seems little differs from the latter.
Created attachment 328073 [details] console debug output (2) no vaapi
I can see there's a thread doing gst_bus_timed_pop_filtered() - why is that still going? That's on your application's side and suggests to me the app hasn't stopped everything it should. This doesn't prevent pipelines from stopping though. Note that you will not receive state change messages for READY->NULL unless you explicitly disable auto flushing of the bus on the pipeline/playbin. It looks like what's happening here is a deadlock between baseparse and typefind when switching or activating modes. (There seem to be multiple typefinds here?) We have fixed some bugs related to this particular issue recently, so I'm going to close this in the hope that it's fixed. Please re-open if it still happens with git master (>= 1.13), thanks! (There's something strange in the stack traces: typefind emits the "have-type" signal, which somehow ends up in javascript (does the app hook into this? why?) and then it goes back into typefind's emit_have_type. As if it didn't return but something else is done inside the have-type signal callback.)
Also, does Pale Moon still use GStreamer nowadays if it's based on Mozilla/FF?