Looks at least partly like an oil_init() failure. What version of liboil is this with and what CPU is this?

Could you do:

  $ cd ~/gst-plugins-base-0.10.16/tests/check/
  $ export GST_DEBUG_NO_COLOR=1
  $ GST_DEBUG=*:5 make elements/playbin.check 2>dbg.log 
  $ bzip2 dbg.log

and attach the log file?

The CPU is Intel Xeon:
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 15
model           : 2
model name      : Intel(R) Xeon(TM) CPU 2.80GHz
stepping        : 7
cpu MHz         : 2800.129
cache size      : 512 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 1
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid xtpr
bogomips        : 5604.07
clflush size    : 64


It is liboil 0.3.12. The library was patched not to use sse at all.


The debug output is too big to attach, you can get it here:
http://www-zeuthen.desy.de/~waschk/dbg.log.bz2

It seems to me like there's something a bit dodgy/broken about your setup:

 $ grep load_plugin..filename 512740-base-unit-test-failure.log | grep decode

load_plugin: filename ../../gst/playback/.libs/libgstdecodebin.so
load_plugin: filename ../../gst/playback/.libs/libgstdecodebin2.so
load_plugin: filename /usr/lib/gstreamer-0.10/libgsturidecodebin.so

This looks like you're mixing plugins from two different -base versions, possibly in combination will a wrongly-setup uninstalled setup or forced plugin paths or something ... (note that at some point the plugin with decodebin2 has been renamed IIRC, so having the .so files from two versions around causes conflicts). The relative paths for the uninstalled .so files suggest that you're not using the GStreamer gst-uninstalled script.

OK, I have removed gst-plugins-base 0.10.15 from the build machine. Now only one test fails, the elements/playbin one with the same error as above. The make check command should call the right gst script, so please fix this.

> OK, I have removed gst-plugins-base 0.10.15 from the build machine.
> Now only one test fails, the elements/playbin one with the same error
> as above. The make check command should call the right gst script, so
> please fix this.

Sorry, it looks like I was a bit quick to declare your setup broken :)

So it seems you're running 'make check' in a gst-plugins-base built against an installed core. 'make check' then uses a test environment like this:

TESTS_ENVIRONMENT = (snip) ...
  GST_PLUGIN_SYSTEM_PATH=    \
  GST_PLUGIN_PATH=$(top_builddir)/gst:$(top_builddir)/sys:$(top_builddir)/ext:$(GST_PLUGINS_DIR)


where GST_PLUGINS_DIR is the directory where the core plugins can be found, which is /usr/lib/gstreamer-0.10/ in this case. So far so good.

The problem seems to be that when the registry scans the available plugins it does it dir-by-dir, replacing any previously loaded plugins/elementfactories by the same name if there are duplicates. So in this case the old installed -base plugins trump the local new ones.

So we need to fix our testing environment to put the local plugins last, I think.

Could you see what happens if you use:

GST_PLUGIN_PATH=$(GST_PLUGINS_DIR):$(top_builddir)/gst:$(top_builddir)/sys:$(top_builddir)/ext

instead? (if it still fails, could you upload another log please?)

I didn't modify the path but I removed the plugins from /usr/lib/gstreamer-0.10/, apart from libgstcoreelements.so and libgstcoreindexers.so which are part of gstreamer 0.10.16. The log of this case is here:
http://www-zeuthen.desy.de/~waschk/dbg.log.bz2

Hrm, it looks like some registry corner-case was triggered, basically libgstdecodebin2.so is cached as plugin in the registry, but without any features (because the one there was was replace by the one in /usr/lib/gstreamer-0.10/*so, which has no disappeared), and it's not updated because timestamp and size of the .so still match.

Could you try 'make clean; make' in -base/gst/playback/  and see if the problem persists? And/or 'rm -base/tests/check/test-registry.xml'.

Indeed, after removing the registry all checks passed. Thanks for your patience.

Brilliant, thanks for confirming.

Should be fixed in -base CVS now:

 2008-02-02  Tim-Philipp Müller  <tim at centricular dot net>

        * tests/check/Makefile.am:
          Fix the tests environment's GST_PLUGIN_PATH: we want the directory
          with the core's plugins first and our local build directories last,
          since we might be building against an installed core, and that
          core's plugin directory may contain older or other versions of
          our own -base plugins, but we really do want to test our local
          ones (if there are multiple plugins or element factories with the
          same name, those inspected last will trump those read in earlier).
          Fixes #512740 for the most part.

Actually, on second though, my analysis wasn't quite right: it's not correct that plugins scanned later replace plugins scanned earlier. If there are multiple plugins with the same name, the one read first prevails. However, element factories may replace earlier-read element factories of the same name, which is then only a problem if plugins change name or elements are split out from one plugin and put into a separate plugin.

Reverted the above, this needs a different fix (if it needs one at all).

*** Bug 559049 has been marked as a duplicate of this bug. ***

I think this is now fixed with with commit in >= 0.10.29.2:

 commit fe4d0e7da67a264ff4f92ff65c4bd89f526a63b5
 Author: Tim-Philipp Müller <tim.muller@collabora.co.uk>
 Date:   Thu Jun 24 13:30:50 2010 +0100

     tests: add plugin loading whitelist to test environment
    
     Only want to load core/-base plugins here.