Bug 58548 - [Gtk+] deadlock in gstreamer video player when exiting fullscreen
Summary: [Gtk+] deadlock in gstreamer video player when exiting fullscreen
Status: RESOLVED WONTFIX
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit Gtk (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks: 55056 63472
  Show dependency treegraph
 
Reported: 2011-04-14 08:55 PDT by Jonathon Jongsma (jonner)
Modified: 2014-03-03 00:18 PST (History)
3 users (show)

See Also:


Attachments
deadlock backtrace (17.71 KB, text/plain)
2011-04-14 08:55 PDT, Jonathon Jongsma (jonner)
no flags Details
full stack trace (178.30 KB, text/plain)
2011-04-29 10:15 PDT, Jonathon Jongsma (jonner)
no flags Details
proposed patch (1.87 KB, patch)
2011-05-04 04:09 PDT, Philippe Normand
no flags Details | Formatted Diff | Diff
deadlock trace observed after patch is applied (40.71 KB, text/plain)
2011-05-11 09:29 PDT, Jonathon Jongsma (jonner)
no flags Details
use async pad blocking (5.78 KB, patch)
2011-05-11 10:15 PDT, Philippe Normand
no flags Details | Formatted Diff | Diff
use async pad blocking (9.57 KB, patch)
2011-05-23 04:59 PDT, Philippe Normand
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jonathon Jongsma (jonner) 2011-04-14 08:55:24 PDT
Created attachment 89589 [details]
deadlock backtrace

Regularly when I try to exit the video player fullscreen mode, the entire browser (epiphany) locks up.  backtrace attached.
Comment 1 Philippe Normand 2011-04-20 06:50:07 PDT
What are the versions of

- epiphany
- webkitgtk
- gst*

?
Comment 2 Jonathon Jongsma (jonner) 2011-04-20 14:43:23 PDT
(In reply to comment #1)
> What are the versions of
> 
> - epiphany
> - webkitgtk
> - gst*
> 
> ?

I'm using debian unstable.  current versions are:
libwebkitgtk-3 1.3.13-4
epiphany-browser 3.0.0-1
libgstreamer0.10-0 0.10.32-6
gstreamer0.10-plugins-base 0.10.32-2
gstreamer0.10-plugins-good 0.10.28-3
gstreamer0.10-plugins-bad 0.10.21-4
Comment 3 Philippe Normand 2011-04-29 08:40:56 PDT
(In reply to comment #2)
> (In reply to comment #1)
> > What are the versions of
> > 
> > - epiphany
> > - webkitgtk
> > - gst*
> > 
> > ?
> 
> I'm using debian unstable.  current versions are:
> libwebkitgtk-3 1.3.13-4
> epiphany-browser 3.0.0-1
> libgstreamer0.10-0 0.10.32-6
> gstreamer0.10-plugins-base 0.10.32-2
> gstreamer0.10-plugins-good 0.10.28-3
> gstreamer0.10-plugins-bad 0.10.21-4

Can't reproduce the error on my laptop (running debian sid/experimental). There have been gstreamer updates since you reported the issue. Can you still reproduce it?

If so it'd probably help to have a stack-trace. Run epiphany in gdb and when the deadlock happens press Ctrl-C in the console then "t a a bt"
Comment 4 Philippe Normand 2011-04-29 08:44:06 PDT
Sorry I missed it in comment 0 ;) The lock happens when the video sink changes from PAUSED to READY but I'd still like to have an overview of all the threads if possible.
Comment 5 Jonathon Jongsma (jonner) 2011-04-29 10:15:08 PDT
Created attachment 91693 [details]
full stack trace

I just tested this again and it seemed a bit harder to reproduce the crash this time for some reason.  But I did manage to reproduce it by playing the demo video at http://videojs.com and fullscreen/un-fullscreening the video repeatedly.  It took about 6 times for the deadlock to occur.  Full stacktrace attached.  I'm a bit surprised that there are 37 threads in the trace.
Comment 6 Philippe Normand 2011-05-04 04:09:18 PDT
Created attachment 92212 [details]
proposed patch

Could you test this please Jonathon?
Comment 7 Philippe Normand 2011-05-04 08:37:43 PDT
Thanks for the review Martin! Indeed I think pad blocking is needed but I'd like confirmation this fixes the bug reported by Jonathon :)
Comment 8 Philippe Normand 2011-05-11 08:10:36 PDT
Please reopen the bug if the issue is still present

Committed r86232: <http://trac.webkit.org/changeset/86232>
Comment 9 Jonathon Jongsma (jonner) 2011-05-11 08:13:15 PDT
Sorry I took so long to reply to this.  I actually managed to compile and test it a couple of days ago, and I was still able to reproduce the deadlock :/
Comment 10 Philippe Normand 2011-05-11 08:15:33 PDT
(In reply to comment #9)
> Sorry I took so long to reply to this.  I actually managed to compile and test it a couple of days ago, and I was still able to reproduce the deadlock :/

Argh :( Do you get the same stack-trace?
Comment 11 Jonathon Jongsma (jonner) 2011-05-11 08:50:19 PDT
oh, damn, I just went back to look at my tree, and it seems that git bz actually failed to apply the patch, but I didn't notice.  Let me rebuild and try to test again.
Comment 12 Philippe Normand 2011-05-11 08:55:22 PDT
Comment on attachment 92212 [details]
proposed patch

This patch landed. Clearing r flag
Comment 13 Jonathon Jongsma (jonner) 2011-05-11 09:29:41 PDT
Created attachment 93131 [details]
deadlock trace observed after patch is applied

Here's a backtrace of the deadlock that I observe after this patch is applied.  Note that when I just fullscreen and un-fullscreened the video, I didn't observe any deadlocks.  But when I added a seek as well, it triggered the lockup.  So something like:

- go to http://videojs.com
- play video
- fullscreen
- un-fullscreen
- fullscreen
- un-fullscreen
- Click progress bar behind current play position (i.e. seek backwards a little ways)
- fullscreen
- un-fullscreen
- lockup

Sometimes it requires several attempts to trigger the lockup.
Comment 14 Jonathon Jongsma (jonner) 2011-05-11 09:33:13 PDT
Re-opening as requested in comment #8
Comment 15 Philippe Normand 2011-05-11 10:15:46 PDT
Created attachment 93141 [details]
use async pad blocking
Comment 16 Philippe Normand 2011-05-11 10:16:50 PDT
Can you try this new patch? It makes sure to remove elements from the pipeline only if the tee src pad blocking succeeded.
Comment 17 Jonathon Jongsma (jonner) 2011-05-11 13:12:40 PDT
No, I still get deadlocks, and I even got a crash as well

One thing that seems worth noting.  it seems that there might be some sort of bad interaction between seeking and fullscreening a video.  For example, if I go to this page http://devfiles.myopera.com/articles/1891/custom-controls-webm-360p.html (and enable the media controls via the right-click menu), then I have the following results:

- If I don't seek at all, I can fullscreen/un-fullscreen repeatedly with no problems, although it's worth noting that I do get some critical warnings on the terminal when I enable fullscreen: 
  (GtkLauncher:10127): GStreamer-CRITICAL **: gst_event_new_new_segment_full: assertion `position != -1' failed
  (GtkLauncher:10127): GStreamer-CRITICAL **: gst_pad_push_event: assertion `event != NULL' failed

- As soon as I seek within the video, the next time I try to enable fullscreen mode, bad things happen.  

In one case, it aborted due to a failed assert:

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff4d97581 in WebCore::HTMLMediaElement::enterFullscreen (this=0x1555250) at ../../Source/WebCore/html/HTMLMediaElement.cpp:2518
2518	    ASSERT(!m_isFullscreen);
(gdb) bt 
#0  0x00007ffff4d97581 in WebCore::HTMLMediaElement::enterFullscreen (this=0x1555250) at ../../Source/WebCore/html/HTMLMediaElement.cpp:2518
#1  0x00007ffff4df9fbd in WebCore::MediaControlFullscreenButtonElement::defaultEventHandler (this=0x173a3f0, event=0x12f8d10)
    at ../../Source/WebCore/html/shadow/MediaControlElements.cpp:805
#2  0x00007ffff4c0c31b in WebCore::EventDispatcher::dispatchEvent (this=0x7fffffffd4b0, event=...)
    at ../../Source/WebCore/dom/EventDispatcher.cpp:345
#3  0x00007ffff4c1d24b in WebCore::MouseEventDispatchMediator::dispatchEvent (this=0x7fffffffd540, dispatcher=0x7fffffffd4b0)
    at ../../Source/WebCore/dom/MouseEvent.cpp:176
#4  0x00007ffff4c0ad35 in WebCore::EventDispatcher::dispatchEvent (node=0x173a3f0, mediator=...)
    at ../../Source/WebCore/dom/EventDispatcher.cpp:60
#5  0x00007ffff4c2aa21 in WebCore::Node::dispatchMouseEvent (this=0x173a3f0, event=..., eventType=..., detail=1, relatedTarget=0x0)
    at ../../Source/WebCore/dom/Node.cpp:2840
#6  0x00007ffff4f8664e in WebCore::EventHandler::dispatchMouseEvent (this=0x7fffe000b808, eventType=..., targetNode=0x173a3f0, clickCount=1, 
    mouseEvent=..., setUnder=true) at ../../Source/WebCore/page/EventHandler.cpp:2010
#7  0x00007ffff4f84ff7 in WebCore::EventHandler::handleMouseReleaseEvent (this=0x7fffe000b808, mouseEvent=...)
    at ../../Source/WebCore/page/EventHandler.cpp:1714
#8  0x00007ffff48ea86f in webkit_web_view_button_release_event (widget=0x6f0350, event=0x16d72a0)
    at ../../Source/WebKit/gtk/webkit/webkitwebview.cpp:814
#9  0x00007ffff3a7c6a8 in _gtk_marshal_BOOLEAN__BOXED (closure=0x699670, return_value=0x7fffffffd980, n_param_values=<value optimized out>, 
    param_values=0x17de0d0, invocation_hint=<value optimized out>, marshal_data=<value optimized out>)
    at /scratch/build-area/gtk+3.0-3.0.8/./gtk/gtkmarshalers.c:85
#10 0x00007ffff17f1e7e in g_closure_invoke (closure=0x699670, return_value=0x7fffffffd980, n_param_values=2, param_values=0x17de0d0, 
    invocation_hint=0x7fffffffd940) at /tmp/buildd/glib2.0-2.28.6/./gobject/gclosure.c:767
#11 0x00007ffff18036e8 in signal_emit_unlocked_R (node=<value optimized out>, detail=0, instance=0x6f0350, emission_return=0x7fffffffdaf0, 
    instance_and_params=0x17de0d0) at /tmp/buildd/glib2.0-2.28.6/./gobject/gsignal.c:3290
#12 0x00007ffff180caa5 in g_signal_emit_valist (instance=<value optimized out>, signal_id=<value optimized out>, 
    detail=<value optimized out>, var_args=<value optimized out>) at /tmp/buildd/glib2.0-2.28.6/./gobject/gsignal.c:2993
#13 0x00007ffff180ced3 in g_signal_emit (instance=<value optimized out>, signal_id=<value optimized out>, detail=<value optimized out>)
    at /tmp/buildd/glib2.0-2.28.6/./gobject/gsignal.c:3040
#14 0x00007ffff3ba237f in gtk_widget_event_internal (widget=0x6f0350, event=0x16d72a0)
    at /scratch/build-area/gtk+3.0-3.0.8/./gtk/gtkwidget.c:6098
#15 0x00007ffff3a7befa in gtk_propagate_event (widget=0x6f0350, event=0x16d72a0) at /scratch/build-area/gtk+3.0-3.0.8/./gtk/gtkmain.c:2597
#16 0x00007ffff3a7c2cb in gtk_main_do_event (event=0x16d72a0) at /scratch/build-area/gtk+3.0-3.0.8/./gtk/gtkmain.c:1872
#17 0x00007ffff36f7832 in gdk_event_source_dispatch (source=<value optimized out>, callback=<value optimized out>, 
    user_data=<value optimized out>) at /scratch/build-area/gtk+3.0-3.0.8/./gdk/x11/gdkeventsource.c:318
#18 0x00007ffff0f274a3 in g_main_dispatch (context=0x63eb20) at /tmp/buildd/glib2.0-2.28.6/./glib/gmain.c:2440
#19 g_main_context_dispatch (context=0x63eb20) at /tmp/buildd/glib2.0-2.28.6/./glib/gmain.c:3013
#20 0x00007ffff0f27c80 in g_main_context_iterate (context=0x63eb20, block=1, dispatch=1, self=<value optimized out>)
    at /tmp/buildd/glib2.0-2.28.6/./glib/gmain.c:3091
#21 0x00007ffff0f282f2 in g_main_loop_run (loop=0xb1e280) at /tmp/buildd/glib2.0-2.28.6/./glib/gmain.c:3299


In another instance, the video stopped updating completely, but the audio kept playing (and the current playing position also kept updating).
Comment 18 Alexis Menard (darktears) 2011-05-13 05:43:07 PDT
(In reply to comment #17)
> No, I still get deadlocks, and I even got a crash as well
> 
> One thing that seems worth noting.  it seems that there might be some sort of bad interaction between seeking and fullscreening a video.  For example, if I go to this page http://devfiles.myopera.com/articles/1891/custom-controls-webm-360p.html (and enable the media controls via the right-click menu), then I have the following results:
> 
> - If I don't seek at all, I can fullscreen/un-fullscreen repeatedly with no problems, although it's worth noting that I do get some critical warnings on the terminal when I enable fullscreen: 
>   (GtkLauncher:10127): GStreamer-CRITICAL **: gst_event_new_new_segment_full: assertion `position != -1' failed
>   (GtkLauncher:10127): GStreamer-CRITICAL **: gst_pad_push_event: assertion `event != NULL' failed
> 
> - As soon as I seek within the video, the next time I try to enable fullscreen mode, bad things happen.  
> 
> In one case, it aborted due to a failed assert:
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x00007ffff4d97581 in WebCore::HTMLMediaElement::enterFullscreen (this=0x1555250) at ../../Source/WebCore/html/HTMLMediaElement.cpp:2518
> 2518        ASSERT(!m_isFullscreen);
> (gdb) bt 
> #0  0x00007ffff4d97581 in WebCore::HTMLMediaElement::enterFullscreen (this=0x1555250) at ../../Source/WebCore/html/HTMLMediaElement.cpp:2518
> #1  0x00007ffff4df9fbd in WebCore::MediaControlFullscreenButtonElement::defaultEventHandler (this=0x173a3f0, event=0x12f8d10)
>     at ../../Source/WebCore/html/shadow/MediaControlElements.cpp:805
> #2  0x00007ffff4c0c31b in WebCore::EventDispatcher::dispatchEvent (this=0x7fffffffd4b0, event=...)
>     at ../../Source/WebCore/dom/EventDispatcher.cpp:345
> #3  0x00007ffff4c1d24b in WebCore::MouseEventDispatchMediator::dispatchEvent (this=0x7fffffffd540, dispatcher=0x7fffffffd4b0)
>     at ../../Source/WebCore/dom/MouseEvent.cpp:176
> #4  0x00007ffff4c0ad35 in WebCore::EventDispatcher::dispatchEvent (node=0x173a3f0, mediator=...)
>     at ../../Source/WebCore/dom/EventDispatcher.cpp:60
> #5  0x00007ffff4c2aa21 in WebCore::Node::dispatchMouseEvent (this=0x173a3f0, event=..., eventType=..., detail=1, relatedTarget=0x0)
>     at ../../Source/WebCore/dom/Node.cpp:2840
> #6  0x00007ffff4f8664e in WebCore::EventHandler::dispatchMouseEvent (this=0x7fffe000b808, eventType=..., targetNode=0x173a3f0, clickCount=1, 
>     mouseEvent=..., setUnder=true) at ../../Source/WebCore/page/EventHandler.cpp:2010
> #7  0x00007ffff4f84ff7 in WebCore::EventHandler::handleMouseReleaseEvent (this=0x7fffe000b808, mouseEvent=...)
>     at ../../Source/WebCore/page/EventHandler.cpp:1714
> #8  0x00007ffff48ea86f in webkit_web_view_button_release_event (widget=0x6f0350, event=0x16d72a0)
>     at ../../Source/WebKit/gtk/webkit/webkitwebview.cpp:814
> #9  0x00007ffff3a7c6a8 in _gtk_marshal_BOOLEAN__BOXED (closure=0x699670, return_value=0x7fffffffd980, n_param_values=<value optimized out>, 
>     param_values=0x17de0d0, invocation_hint=<value optimized out>, marshal_data=<value optimized out>)
>     at /scratch/build-area/gtk+3.0-3.0.8/./gtk/gtkmarshalers.c:85
> #10 0x00007ffff17f1e7e in g_closure_invoke (closure=0x699670, return_value=0x7fffffffd980, n_param_values=2, param_values=0x17de0d0, 
>     invocation_hint=0x7fffffffd940) at /tmp/buildd/glib2.0-2.28.6/./gobject/gclosure.c:767
> #11 0x00007ffff18036e8 in signal_emit_unlocked_R (node=<value optimized out>, detail=0, instance=0x6f0350, emission_return=0x7fffffffdaf0, 
>     instance_and_params=0x17de0d0) at /tmp/buildd/glib2.0-2.28.6/./gobject/gsignal.c:3290
> #12 0x00007ffff180caa5 in g_signal_emit_valist (instance=<value optimized out>, signal_id=<value optimized out>, 
>     detail=<value optimized out>, var_args=<value optimized out>) at /tmp/buildd/glib2.0-2.28.6/./gobject/gsignal.c:2993
> #13 0x00007ffff180ced3 in g_signal_emit (instance=<value optimized out>, signal_id=<value optimized out>, detail=<value optimized out>)
>     at /tmp/buildd/glib2.0-2.28.6/./gobject/gsignal.c:3040
> #14 0x00007ffff3ba237f in gtk_widget_event_internal (widget=0x6f0350, event=0x16d72a0)
>     at /scratch/build-area/gtk+3.0-3.0.8/./gtk/gtkwidget.c:6098
> #15 0x00007ffff3a7befa in gtk_propagate_event (widget=0x6f0350, event=0x16d72a0) at /scratch/build-area/gtk+3.0-3.0.8/./gtk/gtkmain.c:2597
> #16 0x00007ffff3a7c2cb in gtk_main_do_event (event=0x16d72a0) at /scratch/build-area/gtk+3.0-3.0.8/./gtk/gtkmain.c:1872
> #17 0x00007ffff36f7832 in gdk_event_source_dispatch (source=<value optimized out>, callback=<value optimized out>, 
>     user_data=<value optimized out>) at /scratch/build-area/gtk+3.0-3.0.8/./gdk/x11/gdkeventsource.c:318
> #18 0x00007ffff0f274a3 in g_main_dispatch (context=0x63eb20) at /tmp/buildd/glib2.0-2.28.6/./glib/gmain.c:2440
> #19 g_main_context_dispatch (context=0x63eb20) at /tmp/buildd/glib2.0-2.28.6/./glib/gmain.c:3013
> #20 0x00007ffff0f27c80 in g_main_context_iterate (context=0x63eb20, block=1, dispatch=1, self=<value optimized out>)
>     at /tmp/buildd/glib2.0-2.28.6/./glib/gmain.c:3091
> #21 0x00007ffff0f282f2 in g_main_loop_run (loop=0xb1e280) at /tmp/buildd/glib2.0-2.28.6/./glib/gmain.c:3299
> 
> 
> In another instance, the video stopped updating completely, but the audio kept playing (and the current playing position also kept updating).

Folks from the Qt port (yes we also use MediaPlayerGstreamer) can also reproduce that one.
Comment 19 Philippe Normand 2011-05-23 04:59:08 PDT
Created attachment 94400 [details]
use async pad blocking
Comment 20 Philippe Normand 2011-05-23 05:04:50 PDT
(In reply to comment #19)
> Created an attachment (id=94400) [details]
> use async pad blocking

Sorry for the delay on this :(
This new patch fixes the fullscreen issues (locally at least :)) mentionned in comment 17. I can seek and still toggle fullscreen display.

But there's still an issue with the videojs.com demo. I'll continue work on this patch but if you can test this version it would be great.
Comment 21 Philippe Normand 2011-06-01 01:41:52 PDT
Comment on attachment 94400 [details]
use async pad blocking

Anyone tested this patch? It works for me so asking review but it'd still be great to have feedback from the people who reported the bug.
Comment 22 Jonathon Jongsma (jonner) 2011-06-02 07:20:21 PDT
Sorry, I've been busy and haven't had time to test yet.  I'll try to get to it soon.
Comment 23 Alexis Menard (darktears) 2011-06-02 07:35:26 PDT
(In reply to comment #21)
> (From update of attachment 94400 [details])
> Anyone tested this patch? It works for me so asking review but it'd still be great to have feedback from the people who reported the bug.

So I tried it on the Qt port and the video seems to get stuck.

Play the video -> enter full screen -> wait -> stuck

Other scenario is entering fullscreen and leaving it right away. The in page playback is stuck too.
Comment 24 Alexis Menard (darktears) 2011-06-02 07:36:03 PDT
(In reply to comment #23)
> (In reply to comment #21)
> > (From update of attachment 94400 [details] [details])
> > Anyone tested this patch? It works for me so asking review but it'd still be great to have feedback from the people who reported the bug.
> 
> So I tried it on the Qt port and the video seems to get stuck.
> 
> Play the video -> enter full screen -> wait -> stuck
> 
> Other scenario is entering fullscreen and leaving it right away. The in page playback is stuck too.

And it outputs :

(<unknown>:12486): GLib-GObject-CRITICAL **: g_object_get: assertion `G_IS_OBJECT (object)' failed

(<unknown>:12486): GStreamer-CRITICAL **: gst_bin_get_by_name: assertion `GST_IS_BIN (bin)' failed

(<unknown>:12486): GStreamer-CRITICAL **: gst_element_get_static_pad: assertion `GST_IS_ELEMENT (element)' failed

(<unknown>:12486): GStreamer-CRITICAL **: gst_pad_set_blocked_async_full: assertion `GST_IS_PAD (pad)' failed
Comment 25 Philippe Normand 2011-06-02 11:53:49 PDT
Comment on attachment 94400 [details]
use async pad blocking

After more testing on another machine and discussion with Alexis, this patch is not working reliably either. In-window video remains freezed after the fullscreen window was closed.
Comment 26 Ademar Reis 2011-06-03 14:08:45 PDT
Revision r86232 cherry-picked into qtwebkit-2.2 with commit cad942a <http://gitorious.org/webkit/qtwebkit/commit/cad942a>
Comment 27 Philippe Normand 2012-01-16 05:47:26 PST
FWIW I'd like to remove this whole GStreamerGWorld and FullScreenVideoController classes once the Fullscreen API signals land. Hopefully we should be able to plug the Accelerated Compositing bits to the FullScreenController (in WebKit2 at least).
Comment 28 Philippe Normand 2014-03-03 00:18:49 PST
Native fullscreen video playback support was removed.