GNOME Bugzilla – Bug 344748
Fails with non-writable registry
Last modified: 2006-06-16 08:04:33 UTC
Hi, While autobuilding software in Debian, it is forbidden to write data outside of the build directory. Software calling gst-inspect-0.10 in its configure currently fails because of this because gst-inspect-0.10 tries to write a registry in $HOME. IMO, it's ok that the software tries to write a registry if it notices the user doesn't have one, but it shouldn't fail in the case where it can't create the file. In the ideal case, the GStreamer m4 macros wouldn't create any file or directory. Bye,
Sample trace of a failure: [...] LOG (0x8052930 - 0:00:01.335487000) GST_REFCOUNTING( 9980) gstobject.c(352):gst_object_unref:<plugin93> 0x820e898 unref 2->1 DEBUG (0x8052930 - 0:00:01.335578000) GST_REGISTRY( 9980) gstregistry.c(842):gst_registry_scan_path_level:<registry0> registry changed? 1 DEBUG (0x8052930 - 0:00:01.335637000) GST_REGISTRY( 9980) gstregistry.c(869):gst_registry_scan_path:<registry0> registry changed? 1 DEBUG (0x8052930 - 0:00:01.335692000) GST_INIT( 9980) gst.c(691):init_post: writing registry cache DEBUG (0x8052930 - 0:00:01.335830000) GST_REGISTRY( 9980) gstregistry.c(885):_gst_registry_remove_cache_plugins:<registry0> removing cached plugins DEBUG (0x8052930 - 0:00:01.337499000) GST_INIT( 9979) gst.c(708):init_post: parent done waiting on child DEBUG (0x8052930 - 0:00:01.337576000) GST_INIT( 9979) gst.c(720):init_post: child exited normally with return value 0 DEBUG (0x8052930 - 0:00:01.337632000) GST_INIT( 9979) gst.c(721):init_post: parent reading registry cache LOG (0x8052930 - 0:00:01.339514000) GST_ELEMENT_FACTORY( 9979) gstelementfactory.c(164):gst_element_factory_find: no such element factory "playbin" No such element or plugin 'playbin' (user had /foobar as $HOME and runs GST_DEBUG="*:5" gst-inspect-0.10 playbin)
This only happens since the introduction of the fork in the registry creation, during initialization, the process forks, the child builds the registry (probably successfully), can't write it and exits, the parent attempts to read the registry but there's none. It seems to me: 1. that the child should bark something when it can't write the registry: [...] DEBUG (0x8052930 - 0:00:01.250521000) GST_REGISTRY(11770) gstregistry.c(869):gst_registry_scan_path:<registry0> registry changed? 1 DEBUG (0x8052930 - 0:00:01.250544000) GST_INIT(11770) gst.c(691):init_post: writing registry cache DEBUG (0x8052930 - 0:00:01.250610000) GST_REGISTRY(11770) gstregistry.c(885):_gst_registry_remove_cache_plugins:<registry0> removing cached plugins DEBUG (0x8052930 - 0:00:01.251646000) GST_INIT(11769) gst.c(708):init_post: parent done waiting on child DEBUG (0x8052930 - 0:00:01.251691000) GST_INIT(11769) gst.c(720):init_post: child exited normally with return value 0 DEBUG (0x8052930 - 0:00:01.251714000) GST_INIT(11769) gst.c(721):init_post: parent reading registry cache => everything seems fine, but isn't 2. that the parent should bark when it can't read the registry: DEBUG (0x8052930 - 0:00:01.251714000) GST_INIT(11769) gst.c(721):init_post: parent reading registry cache LOG (0x8052930 - 0:00:01.252235000) GST_ELEMENT_FACTORY(11769) gstelementfactory.c(164):gst_element_factory_find: no such element factory "playbin" => everything seems fine, but isn't But this doesn't solve the original problem (GStreamer doesn't work when you can't write any registry). Should I revert the changes in the short term?
Created attachment 67260 [details] [review] proposed fix - refactor registry scanning and writing code into own function, so it can be used by fork() parent when registry writing fails in the child and by the non-fork() code path - make child exit with EXIT_FAILURE exit code if it can't write an updated registry, to make the parent aware that it needs to re-scan stuff itself rather than just read things from the (missing or stale) cache file - re-scan things in fork() parent if the child wanted to write an updated registry but couldn't. This isn't exactly optimal, but at least solves the problems in the unusual case where a registry cannot be written.
This should fix it I think: 2006-06-13 Tim-Philipp Müller <tim at centricular dot net> * gst/gst.c: (scan_and_update_registry), (init_post): If the fork()'ed child process can't write the updated registry cache file to disk for some reason, make it exit with a failure exit code, so that the parent can then re-scan the plugins itself and update the registry structures in memory and work with that (rather than failing when creating elements because seemingly no plugins are available). Refactor registry scanning code into separate function for this and also separate fork() and non-fork() code paths. Fixes #344748.
*** Bug 345068 has been marked as a duplicate of this bug. ***