[gstreamer-bugs] [Bug 638941] New: registry scan/loading race and inconsistency

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=638941
  GStreamer | gstreamer (core) | git

           Summary: registry scan/loading race and inconsistency
    Classification: Desktop
           Product: GStreamer
           Version: git
        OS/Version: Linux
            Status: NEW
          Severity: blocker
          Priority: Normal
         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)
 --> (https://bugzilla.gnome.org/attachment.cgi?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'
failed
FAIL: pipelines/gio

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
attached).

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
gst_registry_add_plugin()
  * 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.