GNOME Bugzilla – Bug 104829
[0.6.3] crash when removing plugin without rerunning gst-register
Last modified: 2004-12-22 21:47:04 UTC
Any pipeline that uses a dynamic element (such as spider) which searches the registry for elements to use will crash (segfault) if that element does no longer exist (e.g. because it was removed). Example: gst-register rm $(libdir)/gstreamer-0.x/libgstwincodec.so gst-launch filesrc location=bla ! spider ! xvideosink will segfault. Shouldn't this display a nice error message telling the user he's a moron for removing elements and maybe even tell the user how he can fix it (re-run gst-register)?
Is this still a problem now that the registry is rebuilt?
Afaik, 0.6.1 had that patch included, and 0.6.1 still has the problem. [rbultje@shrek rbultje]$ gst-launch filesrc location=file.mp3 ! spider ! osssink INFO ( 6726: 0) Initializing GStreamer Core Library version 0.6.1 INFO ( 6726: 0) CPU features: (00000000) MMX SSE GStreamer-ERROR **: No default scheduler name - do you have a registry ? aborting... Aborted [rbultje@shrek rbultje]$ I'll try 0.6.x CVS next.
This happens if - you have no user registry - the system registry is non-writable (duh!) - /usr/lib/gstreamer-0.6/ is modified basically, the code realizes it is supposed to update the registry, but doesn't, since it can't write the system registry.
The following patch may fix it (untested)
Created attachment 18709 [details] [review] patch
But why doesn't it create a user registry instead of crashing? Or is that too obvious?
Because of the line removed in the patch, it never even gets to the point where it attempts to rebuild the registry. If the file doesn't exist, it is not readable, so it fails that test. It seems ok to remove the line, since gst_registry_load() checks for readability (and existence, etc.) as well.
I applied the patch to HEAD, and I think it works.
applied to 0.6.2.1, closed.