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 751032 - SDL example sdlshare2 deadlocks
SDL example sdlshare2 deadlocks
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Linux
: Normal normal
: 1.13.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-06-16 11:11 UTC by Jan Schmidt
Modified: 2017-11-25 00:27 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Jan Schmidt 2015-06-16 11:11:55 UTC 
The tests/examples/gl/sdl/sdlshare2 example showing glimagesink integration doesn't work any more. Everything ends up sleeping on gconds and never wakes up again.

+ Trace 235175

Thread 3 (Thread 0x7fffecf14700 (LWP 26145))

  • #0 syscall
    at ../sysdeps/unix/sysv/linux/x86_64/syscall.S line 38
  • #1 g_cond_wait
    at gthread-posix.c line 1395
  • #2 on_client_draw
    at sdlshare2.c line 193
  • #3 ffi_call_unix64
  • #4 ffi_call
  • #9 <emit signal ??? on instance 0x1127020 [GstGLImageSinkBin]>
    at gsignal.c line 3361
  • #10 _on_client_draw
    at gstglimagesink.c line 177
  • #11 ffi_call_unix64
  • #12 ffi_call
  • #17 <emit signal ??? on instance 0x1136210 [GstGLImageSink]>
    at gsignal.c line 3361
  • #18 gst_glimage_sink_on_draw
    at gstglimagesink.c line 1813
  • #19 gst_gl_window_x11_draw_unlocked
    at gstglwindow_x11.c line 396
  • #20 draw_cb
    at gstglwindow_x11.c line 433
  • #21 _run_message_sync
    at gstglwindow.c line 638
  • #22 _run_message_async
    at gstglwindow.c line 707
  • #23 g_main_context_dispatch
    at gmain.c line 3122
  • #24 g_main_context_dispatch
    at gmain.c line 3737
  • #25 g_main_context_iterate
    at gmain.c line 3808
  • #26 g_main_loop_run
    at gmain.c line 4002
  • #27 gst_gl_context_create_thread
    at gstglcontext.c line 1350
  • #28 g_thread_proxy
    at gthread.c line 764
  • #29 start_thread
    at pthread_create.c line 333
  • #30 clone
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S line 109 






Comment 1


Matthew Waters (ystreet00)





          2015-06-16 12:22:43 UTC
        



Yea, so this is where the whole using "glimagesink as an appsink" thing breaks down.  The condition order is as follows.

The GL thread (where the draw signal is emitted) ends up waiting in the application for the main thread to finish drawing (big no-no in the current thread design).  The main thread in the mean time, is trying to upload the data to GL textures on the GL thread but can't because the GL thread is waiting for the draw signal to finish.  Side note, the streaming thread is also blocked waiting for the redraw to never complete.






Comment 2


Tim-Philipp Müller





          2016-12-21 11:40:50 UTC
        



So what shall we do with this then?






Comment 3


Matthew Waters (ystreet00)





          2016-12-30 05:26:46 UTC
        



Either remove the example as it's useless or rewrite with appsink.






Comment 4


Nicolas Dufresne (ndufresne)





          2017-11-25 00:23:48 UTC
        



Sorry, didn't think of searching existing bug. Its Lubosz that made me notice, as it was relatively simple fix, I fixed it. Though, I think client-draw signal is too tricky for the shared GL context case.

So I think porting this to appsink would serve better, and then remove fakesink example that uses async queues, since this is like trying a bit of appsink.

May I close this bug?