[gstreamer-bugs] [Bug 638941] New: registry scan/loading race and inconsistency
bugzilla at gnome.org
Fri Jan 7 13:36:57 PST 2011
GStreamer | gstreamer (core) | git
Summary: registry scan/loading race and inconsistency
Component: gstreamer (core)
AssignedTo: gstreamer-bugs at lists.sourceforge.net
ReportedBy: bilboed at gmail.com
QAContact: gstreamer-bugs at lists.sourceforge.net
GNOME target: ---
GNOME version: ---
Created an attachment (id=177785)
rm test-registry.reg && rm pipelines/gio &&
GST_DEBUG=2,check:5,*LOAD*:5,*REG*:5 make check -j5 > log-plugin2 2>&1
When running the unit tests in -base, the gio test sometimes fails with the
following error :
Running suite(s): gio
0%: Checks: 1, Failures: 1, Errors: 0
pipelines/gio.c:96:F:general:test_memory_stream:0: Assertion 'src != NULL'
What's actually happening is that it actually attempted to load the libgstgio
from /usr/lib, which was blacklisted and therefore had zero features. And
obviously... it couldn't create a giostreamsrc element since that plugin
doesn't have one.
The local source libgstgio.so does exist, is valid, has all the features.
This only happens with the subprocess scanning.
This is one is tricky... so bare with me for the explanations (debug logs
The registry scan (to create/update test-registry.reg) does the following:
* The parent process scans the various paths for potential .so
* It checks if a potential .so isn't already register
* If there isn't already a registered plugin with the same basename
(libgstFOO.so) it sends it to the child process to be scanned
* CHILD : processes the incoming .so, checks it against a potential
whitelist, and eventually returns the information back to the parent process
* The parent process receives plugin info from the child process and calls
* If a plugin with the same basename isn't already present it adds it
* If a plugin with the same basename is already present it replaces it with
the new one
Where the race happens:
* parent scans potential .so in local source (including the local libgstgio.so)
and sends it to child
* CHILD : eventually sends it back (stress-word : eventually)
* parent scans system-wide paths for potential .so (including libgstgio.so).
=> The problem is that the child might have not sent back the result from
scanning the local libgstgio.so at that time. And therefore the parent process
thinks libgstgio.so is a new plugin and sends it to the child process to scan
* CHILD : sends back the results from scanning the local libgstgio.so
* PARENT : adds it to registry
* CHILD : scans system-wide libgstgio.so, but since we have a whitelist and
it's not in it it is marked as blacklisted and no features are added to it and
sends it back to the parent
* PARENT : adds system-wide libgstgio.so to registry. There already is an
existing libgstgio.so .... and it therefore replaces it by the new
(system-wide, blacklisted, 0 features) libgstgio.so
=> FAILURE ENSUES
How to solve this:
in gst_registry_add_plugin, if there's already an existing same-basename
plugin... check if either the new or existing plugin is blacklisted and make a
*smart* choice on whether to replace the existing plugin by the new one or
ignore the new one.
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.
More information about the Gstreamer-bugs