Created attachment 279765 [details] Backtrace I'm getting lots of random freezes while browsing https://twitter.com I'm using Epiphany 3.20.2-1, Gstreamer 1.8.1-1 and WebKitGTK 2.12.3-1, everything from Debian. It seems that there's a deadlock in Gstreamer while playing some videos, but I cannot reproduce the problem reliably with any video, just by randomly scrolling up and down. I noticed similar problems in Facebook. I'm attaching a backtrace.
Created attachment 279766 [details] Debug output with GST_DEBUG='webkit*:5'
Here I got a crash after a while scrolling and this message on the console: ** ERROR:/home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/gst-plugins-bad-1.8.0/gst-libs/gst/adaptivedemux/gstadaptivedemux.c:1095:gst_adaptive_demux_find_stream_for_pad: code should not be reached
Ah you use 1.8.1 which has this commit, removing the assert: https://cgit.freedesktop.org/gstreamer/gst-plugins-bad/commit/?h=1.8&id=3aee2039591421f4cc8757353034daf0e011a9ce I'll locally bump my jhbuild to 1.8.1 and try to reproduce the problem.
Looks like this was fixed in gstreamer upstream: https://bugzilla.gnome.org/show_bug.cgi?id=763496 Should be shipped in 1.8.2 RSN.
(In reply to comment #4) > Looks like this was fixed in gstreamer upstream: > https://bugzilla.gnome.org/show_bug.cgi?id=763496 I cherry-picked that patch and it looks like I'm still having problems. #0 0x00007fb261a1ba59 in syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 #1 0x00007fb25f96a28c in g_mutex_lock_slowpath (mutex=0x7fb1e40f44f0) at /build/glib2.0-wnDt2X/glib2.0-2.48.1/./glib/gthread-posix.c:1312 #2 0x00007fb25f96aad2 in g_mutex_lock (mutex=<optimized out>) at /build/glib2.0-wnDt2X/glib2.0-2.48.1/./glib/gthread-posix.c:1336 #3 0x00007fb1a7dcccce in gst_adaptive_demux_change_state (element=0x7fb1e40f4520 [GstHLSDemux], transition=GST_STATE_CHANGE_PAUSED_TO_READY) at gstadaptivedemux.c:480 #4 0x00007fb1a81e136d in gst_hls_demux_change_state (element=0x7fb1e40f4520 [GstHLSDemux], transition=GST_STATE_CHANGE_PAUSED_TO_READY) at gsthlsdemux.c:194 #5 0x00007fb25d13b0de in gst_element_change_state () at /usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
Note this is presumably a regression from bug #144040. I'm getting complaints that Facebook hangs with 2.12.3, could it be this same issue?
(In reply to comment #6) > I'm getting complaints that Facebook hangs with 2.12.3, could it be > this same issue? I'm pretty sure that it's the same issue. Both sites are almost unusable because of this.
(In reply to comment #6) > Note this is presumably a regression from bug #144040. > > I'm getting complaints that Facebook hangs with 2.12.3, could it be this > same issue? It's fun that making something work instead of crash is considered a regression. If adaptive streams are broken in gst, or in wk, let's just disable them until someone fix them properly.
Could it be related to this https://bugzilla.gnome.org/show_bug.cgi?id=767480 ?
(In reply to comment #9) > Could it be related to this > https://bugzilla.gnome.org/show_bug.cgi?id=767480 ? Possibly!
mcatanzaro: agomez: These sites were working fine before the fix, right? Maybe we should roll it out. agomez: I think we shouldç agomez: well, "right" agomez: they may be crashing agomez: due to the HLSL bug agomez: but now they are unusable Rolled out in bug #158740 (In reply to comment #10) > (In reply to comment #9) > > Could it be related to this > > https://bugzilla.gnome.org/show_bug.cgi?id=767480 ? > > Possibly! Possibly, but Occam's razor applies... is it more likely that mutexes are broken, or more likely that there's simply a deadlock in our code.
(In reply to comment #11) > Possibly, but Occam's razor applies... is it more likely that mutexes are > broken, or more likely that there's simply a deadlock in our code. To be clear: the GNOME bug is that mutex unlock is broken, so our mutexes are definitely broken. But our hang is on mutex lock, exactly where you'd expect mutexes to hang, hence let's not blame the mutexes for this.
Was a stable release ever made with this fix? Is it enough to backport r202050 on top of 2.12.3 ?
(In reply to comment #13) > Was a stable release ever made with this fix? No, the last stable release was in May. Carlos is busy. :/ > Is it enough to backport > r202050 on top of 2.12.3 ? No, the full fix requires unreleased GStreamer 1.10. :/
I've hit this just opening twitter.com GStreamer 1.10 was already released. Any chance to update our dependencies?