GNOME Bugzilla – Bug 341479
Too many plugins loaded even for up-to-date registry
Last modified: 2006-05-29 09:20:34 UTC
It seems that gst loads all plugins on startup, even in a small app like mixer_applet2. See this IRC conversation: <wingo-pb> BenM: if it is loading all of those plugins it's probably a bug <BenM> can you guys reproduce this <BenM> cat /proc/pid/maps <BenM> on a process that uses gstreamer <BenM> is there any debugging output i can get <wingo-pb> via? <BenM> something <BenM> what can i do to get you more data <wingo-pb> hum <wingo-pb> rhythmbox has video things loaded up <wingo-pb> BenM: GST_DEBUG=5 when running the app <wingo-pb> in the env <wingo-pb> oh wonderful, rhythmbox is loading libtheora. <wingo-pb> that's totally awesome for some definitions of awesome. <slomo_> BenM: i can confirm this behaviour here, registry is definitely up to date * liquiem (n=liquiem@p548B8F9C.dip0.t-ipconnect.de) has joined #gstreamer <BenM> that's not suprising, given this is on ubuntu dapper :-) <ds> GST_DEBUG=GST_REGISTRY:5 gst-launch &>out <wingo-pb> it could be something involving traversing gstplugins for features <BenM> http://www.contrib.andrew.cmu.edu/~bmaurer/gstdbg <wingo-pb> which rhythmbox does as well <wingo-pb> BenM: for what command is that? <BenM> rhythmbox <BenM> i'll try the other one <wingo-pb> well if we can all reproduce it it's unnecessary <BenM> :-) * wingo-pb not going to really get into debugging it right now :) <wingo-pb> but i'd file a bug and someone will look at it soon <wingo-pb> we have a culture of bugzilla points-whoring :)
See also http://bugzilla.gnome.org/show_bug.cgi?id=338339
The patch for #338339 doesn't fix it here
Gstreamer certainly isn't loading all plugins for all cases. It does if we have a stale registry (as we've discussed before, perhaps we should fork() to do this?) The rhythmbox-loading-way-too-much thing is probably related to oggdemux (though that's mostly a guess). Changing summary to reflect problem.
I only get GStreamer loading plugins when it thinks they are dirty and need refreshing in the cache. Probably we can manage to fork that scanning off to a background process so that the libs can be properly unloaded again, which would help with not bloating the parent process. I don't see the actual problem described here though - when I have a clean plugin registry, I only see the plugins I expect being loaded in the maps.
One example is the mixer applet of gnome... slomo@asgard:~$ cat /proc/`pidof mixer_applet2`/maps | grep libgstmusepack b5ed8000-b5ede000 r-xp 00000000 03:01 4321495 /usr/lib/gstreamer-0.10/libgstmusepack.so b5ede000-b5edf000 rw-p 00005000 03:01 4321495 /usr/lib/gstreamer-0.10/libgstmusepack.so slomo@asgard:~$ killall mixer_applet2 slomo@asgard:~$ cat /proc/`pidof mixer_applet2`/maps | grep libgstmusepack b5e0a000-b5e10000 r-xp 00000000 03:01 4321495 /usr/lib/gstreamer-0.10/libgstmusepack.so b5e10000-b5e11000 rw-p 00005000 03:01 4321495 /usr/lib/gstreamer-0.10/libgstmusepack.so The registry is definetely clean at the second start of the applet and when looking at the output of "GST_DEBUG=GST_REGISTRY:3 gst-launch-0.10" there's nothing done with the registry at all thus it must be clean. The same is also true for rhythmbox, banshee, sound-juicer and maybe almost everything here. But as the output of gst-launch-0.10 suggests it's not registry regeneration. slomo@asgard:~$ LC_ALL=C GST_DEBUG=GST_REGISTRY:3 gst-launch-0.10 INFO (0x80509a0 - 0:00:00.045846000) GST_REGISTRY(10570) gstregistryxml.c(557):gst_registry_xml_read_cache: loaded /home/slomo/.gstreamer-0.10/registry.i486.xml in 0.043865 seconds ERROR: pipeline could not be constructed: empty pipeline not allowed.
One thing you could do is to: 1) killall mixer_applet2 and wait for the dialog box, but don't restart it yet 2) run GST_DEBUG=5 /usr/lib/gnome-applets/mixer_applet2 > gst.log 2>&1 3) Click the Reload button in the 'Applet died, reload?' dialog 4) bzip up the gst.log file and attach it here. 5) Profit!
Created attachment 65325 [details] gst.log.bz2 GST_DEBUG_NO_COLOR=1 GST_DEBUG=5 /usr/lib/gnome-applets/mixer_applet2 > gst.log 2>&1
The registry is definitely uptodate as it's (in general) the same output everytime
This log shows a not-up-to-date registry. e.g. (but also many other files): DEBUG (0x8059a68 - 0:00:00.153748000) GST_REGISTRY(18021) gstregistry.c(828):gst_registry_scan_path_level:<registry0> file /usr/lib/gstreamer-0.10/libgstvideoflip.so not yet in registry And eventually: DEBUG (0x8059a68 - 0:00:00.913441000) GST_REGISTRY(18021) gstregistry.c(869):gst_registry_scan_path:<registry0> registry changed? 1 Your registry is at /home/slomo/.gstreamer-0.10/registry.i486.xml, can you check that it's being written?
That file is written. If I delete it, it is recreated after starting a gst application and beginning from that is not rewritten anymore although this debug messages are still in the log.
I've found the problem. It seems that in the most recent packages, the Origin URL and Package Name are blank because a bug in the build system, resulting in empty tags in the registry file for those entries. When the registry code reads it back in, it fails to read a valid string and ignores that entry. I'm still testing the attached patch that allows empty strings in the registry, and working on fixing the build system.
Created attachment 65670 [details] [review] patch for the registry problem
Created attachment 65672 [details] [review] patch against gstreamer-0.10.6 configure script This patch is against the GStreamer 0.10.6 configure script to fix the build problem. The same change needs to be made in the configure scripts for each of the following packages if anyone is using them: gnonlin 0.10.1 & 0.10.4 gstreamer 0.10.5, 0.10.6 gst-plugins-base 0.10.6 & 0.10.7 gst-plugins-good 0.10.3 gst-plugins-bad 0.10.3
So, has anyone got to patch it in common/m4/gst-args.m4 in CVS?
Yes, it was fixed in CVS the same day.