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 112745 - registry has garbage characters
registry has garbage characters
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Normal normal
: 0.6.x
Assigned To: GStreamer Maintainers
Wim Taymans
Depends on:
Blocks:
 
 
Reported: 2003-05-10 23:36 UTC by David Schleef
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
complete registry.xml (13.45 KB, text/plain)
2003-05-10 23:37 UTC, David Schleef
Details

Description David Schleef 2003-05-10 23:36:44 UTC
Occasionally, when I run gst-register in an uninstalled HEAD source tree,
with GST_PLUGIN_PATH set to the gstreamer tree (and also sometimes with the
gst-plugins tree), I will end up with bogus garbage characters in
registry.xml in <nametemplate>s:

<feature typename="GstElementFactory">
<name>fakesink</name>
<longname>Fake Sink</longname>
<class>Sink</class>
<description>Black hole for data</description>
<version>0.7.0.1</version>
<author>Erik Walthinsen &lt;omega@cse.ogi.edu&gt;</author>
<copyright>(C) 1999</copyright>
<padtemplate>
<nametemplate>XÕ^D^H^A</nametemplate>
<direction>sink</direction>
<presence>request</presence>
</padtemplate>
</feature>
Comment 1 David Schleef 2003-05-10 23:37:59 UTC
Created attachment 16418 [details]
complete registry.xml
Comment 2 David Schleef 2003-05-11 05:29:05 UTC
Ok, I figured out why this happens.  Silly me, I was using
GST_PLUGIN_PATH=/home/ds/gst/gstreamer, and gst-register would load
each plugin *twice*.  The problem is that features added to the
elementfactory are only ref'd once.  When a second factory is added
with the same name, the old factory is cleaned in
gst_element_factory_cleanup(), which unrefs all the features, thereby
destroying them.  When the features are added the second time, the
same object pointers are used, since they're static variables in the
pad template factory functions.  Thus destroyed objects are added to
the factory.

I think the appropriate solution is to make sure that factory
functions properly call gst_object_ref(), if they create objects and
store the pointer in a static variable.

The first place to start is GST_PAD_TEMPLATE_FACTORY().  Because of
this, I don't think it's possible to work this solution into 0.6.

Instead, I'm fixing gst_element_factory_cleanup() to not unref the
features.

Comments are welcome.
Comment 3 David Schleef 2003-05-11 05:30:21 UTC
s/features/padtemplates/
Comment 4 Thomas Vander Stichele 2003-06-05 22:18:15 UTC
wim, this looks like something you could say what would be the right
behaviour :)

please comment on this so David can fix it.
Comment 5 David Schleef 2003-07-24 06:48:55 UTC
Ok, I decided that I was definitely right and fixed it in CVS. 
Basically, any macro that creates a function that has a static
variable now has correct refcounting.