Bug 58548

What are the versions of - epiphany - webkitgtk - gst* ?

(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

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

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.

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.

Created attachment 92212 [details] proposed patch Could you test this please Jonathon?

Thanks for the review Martin! Indeed I think pad blocking is needed but I'd like confirmation this fixes the bug reported by Jonathon :)

Please reopen the bug if the issue is still present Committed r86232: <http://trac.webkit.org/changeset/86232>

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

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

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 on attachment 92212 [details] proposed patch This patch landed. Clearing r flag

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.

Re-opening as requested in comment #8

Created attachment 93141 [details] use async pad blocking

Can you try this new patch? It makes sure to remove elements from the pipeline only if the tee src pad blocking succeeded.

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

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

Created attachment 94400 [details] use async pad blocking

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

Sorry, I've been busy and haven't had time to test yet. I'll try to get to it soon.

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

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

Revision r86232 cherry-picked into qtwebkit-2.2 with commit cad942a <http://gitorious.org/webkit/qtwebkit/commit/cad942a>

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

Native fullscreen video playback support was removed.