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 608877 - [typefind] Access to internal fields not threadsafe
[typefind] Access to internal fields not threadsafe
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Normal major
: 0.10.27
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2010-02-03 10:28 UTC by Patrick Radizi
Modified: 2011-01-28 10:24 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
typefindelement: Protect internal fields from concurrent changes from different threads (11.76 KB, patch)
2010-02-05 11:57 UTC, Sebastian Dröge (slomo) 		committed Details | Review
skip object lock in data flow path (2.49 KB, patch)
2011-01-12 12:35 UTC, Stefan Sauer (gstreamer, gtkdoc dev) 		none Details | Review
skip object lock in data flow path (1.73 KB, patch)
2011-01-12 14:06 UTC, Stefan Sauer (gstreamer, gtkdoc dev) 		committed Details | Review

Description Patrick Radizi 2010-02-03 10:28:26 UTC 
I have an application that is using playbin2. Sometimes when changing the state of playbin2 from PAUSED to READY I get the following error:

GStreamer-CRITICAL **: gst_caps_unref: assertion `GST_CAPS_REFCOUNT_VALUE (caps) > 0' failed

I have traced the error to gsttypefindelement.c->gst_type_find_element_change_state()->gst_caps_replace(). 

The error only seems to appear when I do the PASUSED to READY state change shortly after I have set playbin to PLAYING (and before the first frame has reached the audio/video sink).

Looking in the code it's clear that it isn't thread safe. For example gst_type_find_element_have_type() is called from one thread and gst_type_find_element_change_state from another, since they both unref the typefind->caps variable I guess this could be the cause of this error.
Comment 1 Sebastian Dröge (slomo) 2010-02-04 20:17:44 UTC 
Right, there are some thread safety issues with the caps and with some other fields of the typefind element. I'm working on it.
Comment 2 Sebastian Dröge (slomo) 2010-02-05 11:57:38 UTC 
Created attachment 153077 [details] [review]
typefindelement: Protect internal fields from concurrent changes from different threads

Fixes bug #608877.
Comment 3 Sebastian Dröge (slomo) 2010-02-12 10:04:56 UTC 
commit 88736cd6752a9ae49b25ed00ccaf4dbe86b22935
Author: Sebastian Dröge <sebastian.droege@collabora.co.uk>
Date:   Thu Feb 4 21:11:25 2010 +0100

    typefindelement: Protect internal fields from concurrent changes from differ
    
    Fixes bug #608877.
Comment 4 Stefan Sauer (gstreamer, gtkdoc dev) 2011-01-12 12:35:15 UTC 
Created attachment 178124 [details] [review]
skip object lock in data flow path

I believe the locking is overprotective. Am I overlooking something?
Comment 5 Stefan Sauer (gstreamer, gtkdoc dev) 2011-01-12 14:06:55 UTC 
Created attachment 178141 [details] [review]
skip object lock in data flow path

Previous patch contained unrelated edits.