After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 745633 - glimagesink: X11: Race where it creates an external window even if the XID was set
glimagesink: X11: Race where it creates an external window even if the XID wa...
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
1.x
Other Linux
: Normal blocker
: 1.5.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-03-04 19:03 UTC by Thibault Saunier
Modified: 2015-03-11 18:57 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
GST_DEBUG=*gl*:7 debug logs (243.33 KB, application/octet-stream)
2015-03-04 19:03 UTC, Thibault Saunier
Details
stacktrace on tear down (107.51 KB, text/plain)
2015-03-11 18:03 UTC, Thibault Saunier
Details

Description Thibault Saunier 2015-03-04 19:03:10 UTC
Created attachment 298569 [details]
GST_DEBUG=*gl*:7 debug logs

In pitivi we do the following:

Set XID and then pause the pipeline. Usually the sink get embedded properly but in some cases I observe the following:

T0: the XiD is set, gst_glimage_sink_set_window_handle is called, new_window_xid is set

T1: Caps negotiation happens
  -> We create the context
    -> The GL thread is started

T2(glthread): The XWindow is created as part of the creation of the GL thread (in what is called context->choose_format). At that point the XID is not actually set on the GstGLX11Window.

T1: gst_gl_window_set_window_handle is called, still in the process of creating the negotitation in the _ensure_gl_setup function.

T1: In gst_gl_window_x11_set_window_handle we see that the GL mainloop is not running yet (as T2 it is between the call to ->choose_format vmethod and gst_gl_window_run). In that method there is a comment stating:

/* The loop may not exist yet because it's created in GstGLWindow::open                                          
 * which is only called when going from READY to PAUSED state.                                                   
 * If no loop then the parent is directly set in CreateWindow                                                   
 */ 

but in our case the loop is not running yet but we already have the XWindow created with an internal XID.

So we end up never setting the proper Xid to the XWindow and thuse we get an external window poping up.
Comment 1 Matthew Waters (ystreet00) 2015-03-11 13:53:37 UTC
commit bc7a7259f357b0065dd94e0668b5a895d83fa53a
Author: Matthew Waters <matthew@centricular.com>
Date:   Fri Mar 6 15:31:18 2015 +1100

    gl/window: create the main loop/context on init/finalize
    
    Avoids races setting the window handle from the main thread.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=745633
Comment 2 Thibault Saunier 2015-03-11 18:02:54 UTC
I just tested that and since that patch I am getting  the following deadlocks:

When starting:

(gdb) t a a bt

Thread 1 (Thread 0x7fb442fed700 (LWP 28234))

  • #0 syscall
    at ../sysdeps/unix/sysv/linux/x86_64/syscall.S line 38
  • #1 g_cond_wait
    at gthread-posix.c line 1390
  • #2 gst_gl_window_default_send_message
    at gstglwindow.c line 548
  • #3 gst_gl_window_send_message
    at gstglwindow.c line 577
  • #4 gst_glimage_sink_redisplay
    at gstglimagesink.c line 1450
  • #5 gst_glimage_sink_expose
    at gstglimagesink.c line 1087
  • #6 gst_video_overlay_expose
    at videooverlay.c line 435
  • #7 ffi_call_unix64
    at ../src/x86/unix64.S line 76
  • #8 ffi_call
    at ../src/x86/ffi64.c line 525
  • #9 pygi_invoke_c_callable
    at pygi-invoke.c line 628
  • #10 pygi_function_cache_invoke
  • #11 pygi_callable_info_invoke
  • #12 _wrap_g_callable_info_invoke
  • #13 _callable_info_call
  • #14 PyObject_Call
  • #15 PyEval_EvalFrameEx
    at /usr/src/debug/Python-3.4.1/Python/ceval.c line 4485
  • #16 PyEval_EvalFrameEx
    at /usr/src/debug/Python-3.4.1/Python/ceval.c line 4283
  • #17 PyEval_EvalFrameEx
    at remote 0x7fb4157eda48>, _optcre=<_sre.SRE_Pattern at remote 0x7fb41941d180>, _empty_lines_in_value...(truncated), throwflag=<optimized out>) at /usr/src/debug/Python-3.4.1/Python/ceval.c line 2853
  • #18 PyEval_EvalCodeEx
    at /usr/src/debug/Python-3.4.1/Python/ceval.c line 3607
  • #19 function_call
  • #20 PyObject_Call
  • #21 method_call
  • #22 PyObject_Call
  • #23 PyEval_CallObjectWithKeywords
  • #24 PyObject_CallObject
  • #25 pygi_signal_closure_marshal
    at pygi-signal-closure.c line 193
  • #29 <emit signal ??? on instance 0x19aa3b0 [GtkDrawingArea]>
    at gsignal.c line 3365
  • #30 _gtk_widget_draw_internal.part.102
  • #31 _gtk_widget_draw_windows
  • #32 _gtk_widget_draw
  • #33 gtk_widget_send_expose
  • #34 gtk_main_do_event
  • #35 _gdk_window_process_updates_recurse_helper
  • #36 gdk_window_process_updates_internal
  • #37 gdk_window_process_updates_with_mode
  • #38 _g_closure_invoke_va
    at gclosure.c line 831
  • #39 g_signal_emit_valist
    at gsignal.c line 3218
  • #40 g_signal_emit_by_name
    at gsignal.c line 3405
  • #41 gdk_frame_clock_paint_idle
  • #42 gdk_threads_dispatch
  • #43 g_timeout_dispatch
    at gmain.c line 4520
  • #44 g_main_context_dispatch
    at gmain.c line 3111
  • #45 g_main_context_dispatch
    at gmain.c line 3710
  • #46 g_main_context_iterate
    at gmain.c line 3781
  • #47 g_main_context_iteration
    at gmain.c line 3842
  • #48 g_application_run
    at gapplication.c line 2282
  • #49 ffi_call_unix64
    at ../src/x86/unix64.S line 76
  • #50 ffi_call
    at ../src/x86/ffi64.c line 525
  • #51 pygi_invoke_c_callable
    at pygi-invoke.c line 628
  • #52 pygi_function_cache_invoke
  • #53 pygi_callable_info_invoke
  • #54 _wrap_g_callable_info_invoke
  • #55 _callable_info_call
  • #56 PyObject_Call
  • #57 PyEval_EvalFrameEx
    at /usr/src/debug/Python-3.4.1/Python/ceval.c line 4485
  • #58 PyEval_EvalFrameEx
    at /usr/src/debug/Python-3.4.1/Python/ceval.c line 4283
  • #59 PyEval_EvalFrameEx
    at remote 0x7fb4157eda48>, _optcre=<_sre.SRE_Pattern at remote 0x7fb41941...(truncated), throwflag=throwflag@entry=0) at /usr/src/debug/Python-3.4.1/Python/ceval.c line 2853
  • #60 PyEval_EvalFrameEx
    at /usr/src/debug/Python-3.4.1/Python/ceval.c line 4353
  • #61 PyEval_EvalFrameEx
    at /usr/src/debug/Python-3.4.1/Python/ceval.c line 4281
  • #62 PyEval_EvalFrameEx
  • #63 PyEval_EvalCodeEx
    at /usr/src/debug/Python-3.4.1/Python/ceval.c line 3607
  • #64 PyEval_EvalCode
  • #65 run_mod
  • #66 PyRun_FileExFlags
  • #67 PyRun_SimpleFileExFlags
    at /usr/src/debug/Python-3.4.1/Python/pythonrun.c line 1614
  • #68 Py_Main
    at /usr/src/debug/Python-3.4.1/Modules/main.c line 319
  • #69 Py_Main
    at /usr/src/debug/Python-3.4.1/Modules/main.c line 751
  • #70 main
    at /usr/src/debug/Python-3.4.1/Modules/python.c line 69

And if I remove the calls to expose, I get the following when tearing down the pipeline I am getting the stack I attach here (getting an error from bz because my message is too long...)


You can easily reproduce using my gtktimeline branch from https://github.com/thiblahute/pitivi/commits/gtktimeline and running:

  ./tests/validate-tests/runtests -f -l stdout -d

Given you have gst-validate setup.
Comment 3 Thibault Saunier 2015-03-11 18:03:10 UTC
Created attachment 299117 [details]
stacktrace on tear down
Comment 4 Matthew Waters (ystreet00) 2015-03-11 18:57:23 UTC
commit 49b00e44edcf91acfdfd019579b0d3664aa7d959
Author: Matthew Waters <matthew@centricular.com>
Date:   Wed Mar 11 18:49:22 2015 +0000

    gl/x11: don't XGetWindowAttributes every XEvent
    
    fixes a deadlock in xcb where the X window may not exist.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=745633