Bug 158070

Summary: [GTK] [Gstreamer] 2.12.3 freezes randomly when opening media from Twitter
Product: WebKit Reporter: Alberto Garcia <berto>
Component: WebKitGTKAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal CC: agomez, bugs-noreply, cgarcia, mcatanzaro, pnormand, svillar
Priority: P2    
Version: Other   
Hardware: Unspecified   
OS: Unspecified   
See Also: https://bugs.webkit.org/show_bug.cgi?id=144040
Attachments:
Description Flags
Backtrace
none
Debug output with GST_DEBUG='webkit*:5' none

Description Alberto Garcia 2016-05-25 07:06:08 PDT
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.
Comment 1 Alberto Garcia 2016-05-25 07:08:24 PDT
Created attachment 279766 [details]
Debug output with GST_DEBUG='webkit*:5'
Comment 2 Philippe Normand 2016-06-07 01:05:06 PDT
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
Comment 3 Philippe Normand 2016-06-07 01:08:31 PDT
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.
Comment 4 Philippe Normand 2016-06-07 02:29:53 PDT
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.
Comment 5 Alberto Garcia 2016-06-07 04:55:41 PDT
(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
Comment 6 Michael Catanzaro 2016-06-09 12:09:51 PDT
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?
Comment 7 Alberto Garcia 2016-06-09 12:41:35 PDT
(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.
Comment 8 Carlos Garcia Campos 2016-06-09 22:37:05 PDT
(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.
Comment 9 Carlos Garcia Campos 2016-06-09 23:12:42 PDT
Could it be related to this https://bugzilla.gnome.org/show_bug.cgi?id=767480 ?
Comment 10 Philippe Normand 2016-06-10 00:24:28 PDT
(In reply to comment #9)
> Could it be related to this
> https://bugzilla.gnome.org/show_bug.cgi?id=767480 ?

Possibly!
Comment 11 Michael Catanzaro 2016-06-14 09:52:19 PDT
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.
Comment 12 Michael Catanzaro 2016-06-14 12:35:26 PDT
(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.
Comment 13 Alberto Garcia 2016-08-18 07:27:26 PDT
Was a stable release ever made with this fix? Is it enough to backport r202050 on top of 2.12.3 ?
Comment 14 Michael Catanzaro 2016-08-19 08:38:34 PDT
(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. :/
Comment 15 Sergio Villar Senin 2017-01-27 08:18:11 PST
I've hit this just opening twitter.com

GStreamer 1.10 was already released. Any chance to update our dependencies?