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 615655 - [camerabin] shouldn't rely on running GLib main loop
[camerabin] shouldn't rely on running GLib main loop
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other All
: Normal normal
: 0.10.22
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2010-04-13 14:17 UTC by Tim-Philipp Müller
Modified: 2011-04-05 17:41 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
tentative patch, causes problems still (3.43 KB, patch)
2011-04-04 21:55 UTC, Tim-Philipp Müller
none Details | Review
camerabin: don't rely on the application running the default GLib main loop (4.26 KB, patch)
2011-04-05 15:28 UTC, Thiago Sousa Santos
committed Details | Review

Description Tim-Philipp Müller 2010-04-13 14:17:02 UTC
Subject says it all.

gstcamerabin.c-3283-        /* Calling callback directly will deadlock in
gstcamerabin.c-3284-           imagebin state change functions */
gstcamerabin.c:3285:        g_idle_add_full (G_PRIORITY_HIGH, gst_camerabin_imgbin_finished, camera,
gstcamerabin.c-3286-            NULL);

Elements shouldn't rely on a running GLib main loop iterating the default main context.
Comment 1 Stefan Sauer (gstreamer, gtkdoc dev) 2010-04-15 10:33:10 UTC
Right now the best way to solve this would be to detach imgbin from the rest using appsrc/appsink. Then we can even have a pool of imagebins and we can control the states without g_idle_add.

For the record, if we just remove the g_idle_add as it is now and make a direct call, we get stuck in.

gstbasesink.c:4741       GST_PAD_PREROLL_LOCK (basesink->sinkpad);

Thread 3 (Thread 0x7f34d925b910 (LWP 3144))

  • #0 __lll_lock_wait
    from /lib/libpthread.so.0
  • #1 _L_lock_949
    from /lib/libpthread.so.0
  • #2 pthread_mutex_lock
    from /lib/libpthread.so.0
  • #3 gst_base_sink_change_state
    at gstbasesink.c line 4741
  • #4 gst_element_change_state
    at gstelement.c line 2531
  • #5 gst_element_set_state_func
    at gstelement.c line 2487
  • #6 gst_bin_element_set_state
    at gstbin.c line 2121
  • #7 gst_bin_change_state_func
    at gstbin.c line 2420
  • #8 gst_camerabin_image_change_state
    at camerabinimage.c line 225
  • #9 gst_element_change_state
    at gstelement.c line 2531
  • #10 gst_element_set_state_func
    at gstelement.c line 2487
  • #11 gst_camerabin_imgbin_finished
    at gstcamerabin.c line 3472

Maybe there is a easier fix then then appsrc/appsink change.
Comment 2 Tim-Philipp Müller 2010-04-15 10:45:48 UTC
Right, you can't do a state change from within the streaming thread.

Another alternative would be a helper thread iterating a custom GMainContext (or just a one-shot start-thread, do state change, exit thread approach without any main context / main loop iteration) - depends how often this is needed I guess.
Comment 3 Thiago Sousa Santos 2010-05-25 23:37:50 UTC
I'm working on the detaching with appsink/appsrc.
Comment 4 Tim-Philipp Müller 2011-04-04 21:55:47 UTC
Created attachment 185155 [details] [review]
tentative patch, causes problems still
Comment 5 Thiago Sousa Santos 2011-04-05 15:28:49 UTC
Created attachment 185211 [details] [review]
camerabin: don't rely on the application running the default GLib main loop

Improved patch, no more failures.

Now it checks if the pad still exists when trying to unblock it.
Comment 6 Thiago Sousa Santos 2011-04-05 17:41:24 UTC
commit 9c5863ad3548cec9064b1b3edf04ddded70f1846
Author: Tim-Philipp Müller <tim.muller@collabora.co.uk>
Date:   Wed Dec 15 10:39:24 2010 +0000

    camerabin: don't rely on the application running the default GLib main loop
    
    Don't use g_idle_add() and friends to schedule things we can't do from the
    streaming thread in another thread. The app may not be running the default
    GLib main loop. Instead, just spawn a thread.
    
    Also, we need to care for when acessing a pad variable, as another thread
    might have taken camerabin to NULL while this gst_camerabin_imgbin_finished
    didn't run.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=615655