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 344900 - A Blank Package name cause Registry Dump everytime gstreamer runs
A Blank Package name cause Registry Dump everytime gstreamer runs
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
0.10.6
Other All
: Normal minor
: 0.10.7
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2006-06-14 18:59 UTC by Keith Preston
Modified: 2006-06-15 19:49 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Keith Preston 2006-06-14 18:59:19 UTC
Please describe the problem:
This problem only comes up with an incorrect definition of a plugin (incorrect in the sense that it has a blank package name).  However it did show a flaw in the XML registry  system that should be fixed, although it should be fairly easy.  The basic problem is that initialization from a pluging will accept a blank package, however if this is written to the cache and read back out of the cache, it is not parsed correctly.

Because of a build system problem which has been patch, I ended up with libcoreelement having a package name of "".   The first time this plugin loads it will cause a registry cache to dump out.   In the xml it will have a blank package, i.e. <package></package>.  However the next time that the plugin loads it will error out when reading this description back in (message is "problem reading plugin").  I believe that this is a problem in the function read_string.  It would seem to be returning a 0 when two corresponding tags are right next to each other.

Steps to reproduce:
1. Quite simply change your XML cache (.gstreamer/registry.*.xml) and change one of the plugins package name to "" (i.e. <package></package>)
2. 
3. 


Actual results:
If you do this step, everytime gst-launch is invoked it will re-write out the xml cache in full (slows down start up time)   I could especially see this in scratchbox sbrshd where NFS writes are slow.   It was causing a 20-30 second delay

Expected results:


Does this happen every time?
Yes

Other information:
Comment 1 Edward Hervey 2006-06-14 21:27:10 UTC
This probem is fixed in 0.10.8 AFAIK. Can you try with latest releases ?
Comment 2 Wim Taymans 2006-06-15 16:39:36 UTC
Yup, was fixed.

 * gst/gstregistryxml.c: (read_string), (load_pad_template),
 (load_feature), (load_plugin):
 Allow empty strings for some of the plugin fields so we don't
 drop valid plugin entries that were written out correctly.