GNOME Bugzilla – Bug 669789
gstreamer not robust against full homedir (due to registry)
Last modified: 2018-05-04 14:59:27 UTC
I ran this tutorial (http://developer.gnome.org/gnome-devel-demos/unstable/guitar-tuner.vala.html.en) on a 32-bit and a 64-bit machine. On the 32-bit, everything works well. On the 64-bit it appears that Gst.ElementFactory.make ("audiotestsrc","source") is returning nil. When I run the program, and I click on any of the buttons, I get this error: GLib-GObject-CRITICAL **: g_object_set: assertion `G_IS_OBJECT (object)' failed GStreamer-CRITICAL **: gst_bin_add: assertion `GST_IS_ELEMENT (element)' failed GStreamer-CRITICAL **: gst_bin_add: assertion `GST_IS_ELEMENT (element)' failed GStreamer-CRITICAL **: gst_element_link_pads_full: assertion `GST_IS_ELEMENT (src)' failed Inserting a print statement after the call like so: source = Gst.ElementFactory.make ("audiotestsrc", "source"); print("source is %p\n", source); The print statement shows this: source is (nil) I have installed everything listed here: https://live.gnome.org/DeveloperTools/Installation/Fedora (to the best of my knowledge). This is on Fedora16. The only difference I am aware of on the two machines is the architecture. Please let me know if I am missing something, or if the tutorial or instructions need to be adjusted for 64-bit machines. Since this is a tutorial aimed at new developers I believe it is important that it works easily and that the instructions aren't missing packages that should be installed.
I'm probably doing something incredibly stupid, but I'm trying to reproduce this (at the Brno Gnome Docs Hackfest), and I'm running into a problem. I've followed the tutorial through the section labelled "Build the code for the first time", but it isn't building correctly. As far as I know, I've installed all the prerequisite devel libraries, etc. I'm also building on Fedora 16 (completely up to date) on a 64-bit install. make all-recursive make[1]: Entering directory `/home/jsmith/guitar-tuner' Making all in src make[2]: Entering directory `/home/jsmith/guitar-tuner/src' CC guitar_tuner.o guitar_tuner.c:23:18: fatal error: glib.h: No such file or directory compilation terminated. make[2]: *** [guitar_tuner.o] Error 1 make[2]: Leaving directory `/home/jsmith/guitar-tuner/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/jsmith/guitar-tuner' make: *** [all] Error 2 It seems that something isn't finding the necessary glib.h header. (If I start a new project in Anjuta without any external libraries, I get the same error, so I don't think it has anything to do with gstreamer in this case.)
I think that it is unlikely to be a 64-bit versus 32-bit issue, but it could just be that the element ‘audiotestsrc’ does not exist. This can be checked by executing: gst-inspect audiotestsrc in a terminal, which will print out information about that element, or if it is not found. Otherwise, enabling GStreamer debugging might give some hints. Try running the application in a terminal with: GST_DEBUG=2 ./guitar-tuner and look for some useful message (there will probably be a lot of less useful messages too!). There is more information about GStreamer debugging at: http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html/gst-running.html
While looking into this I noticed that ~ was full and recalled that gstreamer creates its registry of available plugins there and guessed it might be corrupted. Sure enough, freeing up some extra space and deleting the registry fixed the problem. Reassigning to gstreamer.
Someone doesn't have a GST_DEBUG=*:5 log of these failures by any chance? Not sure what's happening here. The handling looks ok to me: it writes to a temp file, and checks the return values of write/fsync/close and removes the partial/broken temp file if there was an error (there's a code path where the broken temp file isn't removed, but I don't see how that could have any bad side-effects). I have tried to reproduce this using: $ mkdir ~/tinyfs $ sudo mount -osize=400k tmpfs ~/tinyfs/ -t tmpfs $ GST_REGISTRY=/home/tpm/tinyfs/registry.test gst-inspect-0.10 audiotestsrc but only get the ERROR messages in the debug log (and a left-over temp file which should have been removed) Subsequent calls fail in the same way.
I have cleaned out ~ since, so no longer have the info :-(
Another thing: even if the registry on file is incomplete or nonexistant, and writing the registry failed for whatever reason, the in-memory registry should still be correct. gst_init() it should read the registry cache into memory if it exists, and then compare it against the available plugins, to see if there are plugins it doesn't know about yet, or that have been removed, or that have changed since last inspected. If there is a discrepancy between the registry in memory and the files available, it will try to update the registry in memory. Lastly, if there were any changes, it will try to write an updated cache to disk, so we don't have to do the whole re-inspect dance on the next gst_init() in another process. What seems more likely to me is that something went wrong during plugin inspection and the plugin got "blacklisted" (which happens when plugins crash during inspection or can't be loaded for whatever reason). There's bug #648010 ("Better handling of blacklisted plugins: re-scan occasionally, store reason for blacklisting") about that.
I think this may be / have been caused by liborc crashing if the $HOME was full.
Closing due to lack of information for so long. If one can reproduce the issue, please re-open.