Bug 167861 – [GStreamer] Deadlock when media player is destroyed

• Status: RESOLVED
• Resolution: FIXED
• Component: Media

[Bastien Nocera]

epiphany-3.22.5-1.fc25.x86_64
webkitgtk4-2.14.3-1.fc25.x86_64

After a while, epiphany will only load one out of every 2 or 3 tabs I open, blocking others, and blocking keyboard shortcuts at the same time.
This might have happened after loading a web page where a video was playing through HTML5.

I use "one-secondary-process-per-web-view" as the process model but with a maximum of 5, which might explain why hung tabs don't "go away" (no new web process is created).

The backtrace of the hang:
#0  0x00007ff1845b1460 in pthread_cond_wait@@GLIBC_2.3.2 () at /lib64/libpthread.so.0
#1  0x00007ff17c71a50c in std::condition_variable::wait(std::unique_lock<std::mutex>&) () at /lib64/libstdc++.so.6
#2  0x00007ff187584d08 in WTF::ParkingLot::parkConditionallyImpl(void const*, WTF::ScopedLambda<bool ()> const&, WTF::ScopedLambda<void ()> const&, std::chrono::time_point<std::chrono::_V2::steady_clock, std::chrono::duration<long, std::ratio<1l, 1000000000l> > >) (address=address@entry=0x55e4de5171d0, validation=..., beforeSleep=..., timeout=timeout@entry=...)
    at /usr/src/debug/webkitgtk-2.14.3/Source/WTF/wtf/ParkingLot.cpp:601
#3  0x00007ff18757b1e1 in WTF::ParkingLot::parkConditionally<WTF::ParkingLot::ParkResult WTF::ParkingLot::compareAndPark<unsigned char, int>(WTF::Atomic<unsigned char> const*, int)::{lambda()#1}, WTF::ParkingLot::ParkResult WTF::ParkingLot::compareAndPark<unsigned char, int>(WTF::Atomic<unsigned char> const*, int)::{lambda()#2}>(void const*, WTF::ParkingLot::ParkResult WTF::ParkingLot::compareAndPark<unsigned char, int>(WTF::Atomic<unsigned char> const*, int)::{lambda()#1} const&, WTF::ParkingLot::ParkResult WTF::ParkingLot::compareAndPark<unsigned char, int>(WTF::Atomic<unsigned char> const*, int)::{lambda()#2} const&, std::chrono::time_point<WTF::ParkingLot::ParkResult WTF::ParkingLot::compareAndPark<unsigned char, int>(WTF::Atomic<unsigned char> const*, int)::{lambda()#2} const::_V2::steady_clock, WTF::ParkingLot::ParkResult WTF::ParkingLot::compareAndPark<unsigned char, int>(WTF::Atomic<unsigned char> const*, int)::{lambda()#2} const::duration<long, std::ratio<1l, 1000000000l> > >) (timeout=..., beforeSleep=..., validation=..., address=0x55e4de5171d0) at /usr/src/debug/webkitgtk-2.14.3/Source/WTF/wtf/ParkingLot.h:77
#4  0x00007ff18757b1e1 in WTF::ParkingLot::compareAndPark<unsigned char, int>(WTF::Atomic<unsigned char> const*, int) (expected=3, address=0x55e4de5171d0)
    at /usr/src/debug/webkitgtk-2.14.3/Source/WTF/wtf/ParkingLot.h:92
#5  0x00007ff18757b1e1 in WTF::LockBase::lockSlow() (this=this@entry=0x55e4de5171d0) at /usr/src/debug/webkitgtk-2.14.3/Source/WTF/wtf/Lock.cpp:71
#6  0x00007ff188f35e5e in WTF::LockBase::lock() (this=0x55e4de5171d0) at /usr/src/debug/webkitgtk-2.14.3/Source/WTF/wtf/Lock.h:61
#7  0x00007ff188f35e5e in WTF::Locker<WTF::LockBase>::lock() (this=<synthetic pointer>) at /usr/src/debug/webkitgtk-2.14.3/Source/WTF/wtf/Locker.h:68
#8  0x00007ff188f35e5e in WTF::Locker<WTF::LockBase>::Locker(WTF::LockBase&) (lockable=..., this=<synthetic pointer>) at /usr/src/debug/webkitgtk-2.14.3/Source/WTF/wtf/Locker.h:41
#9  0x00007ff188f35e5e in VideoRenderRequestScheduler::stop() (this=0x55e4de5171d0) at /usr/src/debug/webkitgtk-2.14.3/Source/WebCore/platform/graphics/gstreamer/VideoSinkGStreamer.cpp:94
#10 0x00007ff188f35e5e in webkitVideoSinkUnlock(GstBaseSink*) (baseSink=0x55e4de517480) at /usr/src/debug/webkitgtk-2.14.3/Source/WebCore/platform/graphics/gstreamer/VideoSinkGStreamer.cpp:283
#11 0x00007ff18390379d in gst_base_sink_change_state () at /lib64/libgstbase-1.0.so.0
#12 0x00007ff18360c6ee in gst_element_change_state () at /lib64/libgstreamer-1.0.so.0
#13 0x00007ff18360ce5f in gst_element_set_state_func () at /lib64/libgstreamer-1.0.so.0
#14 0x00007ff1835eb1ad in gst_bin_change_state_func () at /lib64/libgstreamer-1.0.so.0
#15 0x00007ff0d3df6d44 in fps_display_sink_change_state () at /usr/lib64/gstreamer-1.0/libgstdebugutilsbad.so
#16 0x00007ff18360c6ee in gst_element_change_state () at /lib64/libgstreamer-1.0.so.0
#17 0x00007ff18360ce5f in gst_element_set_state_func () at /lib64/libgstreamer-1.0.so.0
#18 0x00007ff1835eb1ad in gst_bin_change_state_func () at /lib64/libgstreamer-1.0.so.0
#19 0x00007ff18360c6ee in gst_element_change_state () at /lib64/libgstreamer-1.0.so.0
#20 0x00007ff18360ce5f in gst_element_set_state_func () at /lib64/libgstreamer-1.0.so.0
#21 0x00007ff1835eb1ad in gst_bin_change_state_func () at /lib64/libgstreamer-1.0.so.0
#22 0x00007ff0d95c61e8 in gst_play_sink_change_state () at /usr/lib64/gstreamer-1.0/libgstplayback.so
#23 0x00007ff18360c6ee in gst_element_change_state () at /lib64/libgstreamer-1.0.so.0
#24 0x00007ff18360ce5f in gst_element_set_state_func () at /lib64/libgstreamer-1.0.so.0
#25 0x00007ff1835eb1ad in gst_bin_change_state_func () at /lib64/libgstreamer-1.0.so.0
#26 0x00007ff1836306ca in gst_pipeline_change_state () at /lib64/libgstreamer-1.0.so.0
#27 0x00007ff0d95b78df in gst_play_bin_change_state () at /usr/lib64/gstreamer-1.0/libgstplayback.so
#28 0x00007ff18360c6ee in gst_element_change_state () at /lib64/libgstreamer-1.0.so.0
#29 0x00007ff18360ce5f in gst_element_set_state_func () at /lib64/libgstreamer-1.0.so.0
#30 0x00007ff188f27216 in WebCore::MediaPlayerPrivateGStreamer::changePipelineState(GstState) (this=this@entry=0x7ff0ea09ca00, newState=newState@entry=GST_STATE_PAUSED)
    at /usr/src/debug/webkitgtk-2.14.3/Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp:354
#31 0x00007ff188f29d03 in WebCore::MediaPlayerPrivateGStreamer::updateStates() (this=this@entry=0x7ff0ea09ca00)
    at /usr/src/debug/webkitgtk-2.14.3/Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp:1438
#32 0x00007ff188f2aaf7 in WebCore::MediaPlayerPrivateGStreamer::handleMessage(_GstMessage*) (this=0x7ff0ea09ca00, message=0x7ff080001e20)
    at /usr/src/debug/webkitgtk-2.14.3/Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp:948
#33 0x00007ff187586dbd in WTF::Function<void ()>::operator()() const (this=<synthetic pointer>) at /usr/src/debug/webkitgtk-2.14.3/Source/WTF/wtf/Function.h:50
#34 0x00007ff187586dbd in WTF::RunLoop::performWork() (this=0x7ff1727f7000) at /usr/src/debug/webkitgtk-2.14.3/Source/WTF/wtf/RunLoop.cpp:122
#35 0x00007ff1875ad619 in WTF::RunLoop::<lambda(gpointer)>::operator() (__closure=0x0, userData=<optimized out>) at /usr/src/debug/webkitgtk-2.14.3/Source/WTF/wtf/glib/RunLoopGLib.cpp:66
#36 0x00007ff1875ad619 in WTF::RunLoop::<lambda(gpointer)>::_FUN(gpointer) () at /usr/src/debug/webkitgtk-2.14.3/Source/WTF/wtf/glib/RunLoopGLib.cpp:68
#37 0x00007ff180c49e42 in g_main_context_dispatch () at /lib64/libglib-2.0.so.0
#38 0x00007ff180c4a1c0 in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0
#39 0x00007ff180c4a4e2 in g_main_loop_run () at /lib64/libglib-2.0.so.0
#40 0x00007ff1875aded0 in WTF::RunLoop::run() () at /usr/src/debug/webkitgtk-2.14.3/Source/WTF/wtf/glib/RunLoopGLib.cpp:94
#41 0x00007ff188184fa9 in WebKit::ChildProcessMain<WebKit::WebProcess, WebKit::WebProcessMain>(int, char**) (argc=<optimized out>, argv=0x7ffe0270a918)
    at /usr/src/debug/webkitgtk-2.14.3/Source/WebKit2/Shared/unix/ChildProcessMain.h:61
#42 0x00007ff17bd9f401 in __libc_start_main () at /lib64/libc.so.6
#43 0x000055e4da2cdc5a in _start ()

[Carlos Garcia Campos]

This is a deadlock, main thread in webkitVideoSinkUnlock while compositing thread is in webkitVideoSinkRender. I think I fixed this in r211357. I tried to reproduce this the other day in trunk and I was unable.

[Bastien Nocera]

(In reply to comment #1)
> This is a deadlock, main thread in webkitVideoSinkUnlock while compositing
> thread is in webkitVideoSinkRender. I think I fixed this in r211357. I tried
> to reproduce this the other day in trunk and I was unable.

Is that version in the release I'm using? Or should I ask Michael to backport it?

[Carlos Garcia Campos]

(In reply to comment #2)
> (In reply to comment #1)
> > This is a deadlock, main thread in webkitVideoSinkUnlock while compositing
> > thread is in webkitVideoSinkRender. I think I fixed this in r211357. I tried
> > to reproduce this the other day in trunk and I was unable.
> 
> Is that version in the release I'm using? Or should I ask Michael to
> backport it?

What release are you using? It's in 2.15.4, but not in 2.14.3. If you are using 2.15.4 then it's not fixed.

[Bastien Nocera]

(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > This is a deadlock, main thread in webkitVideoSinkUnlock while compositing
> > > thread is in webkitVideoSinkRender. I think I fixed this in r211357. I tried
> > > to reproduce this the other day in trunk and I was unable.
> > 
> > Is that version in the release I'm using? Or should I ask Michael to
> > backport it?
> 
> What release are you using? It's in 2.15.4, but not in 2.14.3. If you are
> using 2.15.4 then it's not fixed.

Comment 0 :)

I'm using 2.14.3

[Carlos Garcia Campos]

(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> > > (In reply to comment #1)
> > > > This is a deadlock, main thread in webkitVideoSinkUnlock while compositing
> > > > thread is in webkitVideoSinkRender. I think I fixed this in r211357. I tried
> > > > to reproduce this the other day in trunk and I was unable.
> > > 
> > > Is that version in the release I'm using? Or should I ask Michael to
> > > backport it?
> > 
> > What release are you using? It's in 2.15.4, but not in 2.14.3. If you are
> > using 2.15.4 then it's not fixed.
> 
> Comment 0 :)
> 
> I'm using 2.14.3

phew, then maybe it's indeed fixed by r211357. I plan to make 2.14.4 this week including that fix.

[Michael Catanzaro]

(In reply to comment #2)
> Is that version in the release I'm using? Or should I ask Michael to
> backport it?

Carlos handles all the backports!

Anyway, I'm going to close this since it's already on the backports list and we think it's fixed in trunk. If you can reproduce in 2.14.4 once that's released, then we are wrong, so please complain or reopen in that case.

[Bastien Nocera]

<KaL> hadess: deadlock is still here :-/ I think i have a fix
<KaL> feel free to reopen the bug

[Carlos Garcia Campos]

I finally managed to reliably reproduce this with yelp :-) And the problem is that we are calling notifyDone() for the draw mutex without taking the lock.

[Carlos Garcia Campos]

Created attachment 300801 [details]
Patch

[Carlos Garcia Campos]

Committed r211815: <http://trac.webkit.org/changeset/211815>