Bug 158070 – [GTK] [Gstreamer] 2.12.3 freezes randomly when opening media from Twitter

• Component: WebKitGTK
• Status: RESOLVED FIXED

[Alberto Garcia]

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.

[Alberto Garcia]

Created attachment 279766 [details]
Debug output with GST_DEBUG='webkit*:5'

[Philippe Normand]

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

[Philippe Normand]

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.

[Philippe Normand]

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.

[Alberto Garcia]

(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

[Michael Catanzaro]

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?

[Alberto Garcia]

(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.

[Carlos Garcia Campos]

(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.

[Carlos Garcia Campos]

Could it be related to this https://bugzilla.gnome.org/show_bug.cgi?id=767480 ?

[Philippe Normand]

(In reply to comment #9)
> Could it be related to this
> https://bugzilla.gnome.org/show_bug.cgi?id=767480 ?

Possibly!

[Michael Catanzaro]

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.

[Michael Catanzaro]

(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.

[Alberto Garcia]

Was a stable release ever made with this fix? Is it enough to backport r202050 on top of 2.12.3 ?

[Michael Catanzaro]

(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. :/

[Sergio Villar Senin]

I've hit this just opening twitter.com

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