GNOME Bugzilla – Bug 615357
[macosx] Handle multi-arch plugin-scanner
Last modified: 2011-12-14 12:08:30 UTC
When running gstreamer 0.10.26 or newer, everything installs and runs normally except gst-plugins-scanner. When gst-plugins-scaner is invoked either manually from a terminal emulator or externally (e.g. via Firefox), the process demands 100% of available CPU cycles and doesn't stop until it is killed. This behavior has been confirmed on Mac OS 10.6 but may occur on previous versions as well. Please refer to http://trac.macports.org/ticket/23823 for further details.
From the debug output of the macports bug it looks like the scanner still runs but doesn't send any information back to the parent process via the pipe. I guess after some timeout the plugin scanner process should be killed and the current plugin should be blacklisted.
It looks to me like the debug output in that bug has been obtained by running gst-plugin-scanner directly from the command line. That won't work. It will wait for input on stdin, and it's not surprising that it's spinning until it gets some input. The plugin scanner needs to be spawned via libgstreamer. Can you get us the GST_DEBUG=*:5 output when starting firefox from the command line? Does this also happen when you run e.g. gst-inspect-0.10?
Created attachment 158621 [details] debug output from running firefox output from: GST_DEBUG=*:5 firefox-x11-devel-standalone
And here is from sampling while run from firefox: Call graph: 8762 Thread_2051503 DispatchQueue_1: com.apple.main-thread (serial) 8762 start 8762 main 8762 _gst_plugin_loader_client_run 8762 exchange_packets 8761 read_one 8737 read 24 read_one 1 dyld_stub_read Total number in stack (recursive counted multiple, when >=5): Sort by top of stack, same collapsed (when >= 5): read 8737 read_one 24 Also, debug spew stopped once entering this state.
Re-opening, since log has been provided.
I had a very similar issue, I figured it was related with the elements calling liboil_init(). Rebuilding liboil with the 2 patches there fixed the issue for me... http://trac.macports.org/browser/trunk/dports/devel/liboil/files/
Ping. This is a pretty nasty issue. Logging has been provided as requested. What is holding this up? Philippe's solution doesn't work here. I've got a MacPorts provided liboil (including those patches).
This makes gstreamer completely unusable on Mac OS X. Can you *please* address this bug or ask for more information?
Does it still fail with gstreamer 0.10.30 (or better, latest 0.10.31 pre-releases) ?
Yes, it still fails with 0.10.30.
Actually, now it crashes firefox rather than hanging it. I think the problem has to do with architecture differences. If I execute a 64bit firefox-4.0b7, it works fine now. If I execute a 32bit firefox-3.6.12, it fails. ~ $ GST_DEBUG=*:5 firefox-x11-standalone 0:00:00.000087000 4970 0x1f0cb80 LOG GST_DEBUG gstinfo.c:1255:for_each_threshold_by_entry: category default matches pattern 0x4b98350 - gets set to level 5 0:00:00.000277000 4970 0x1f0cb80 INFO GST_INIT gst.c:599:init_pre: Initializing GStreamer Core Library version 0.10.30 0:00:00.000321000 4970 0x1f0cb80 INFO GST_INIT gst.c:600:init_pre: Using library installed in /opt/local/lib 0:00:00.000371000 4970 0x1f0cb80 INFO GST_INIT gst.c:610:init_pre: Darwin vincent.local 10.6.0 Darwin Kernel Version 10.6.0: Wed Nov 10 18:13:17 PST 2010; root:xnu-1504.9.26~3/RELEASE_I386 i386 0:00:00.000579000 4970 0x1f0cb80 INFO GST_INIT gstquery.c:105:_gst_query_initialize: init queries 0:00:00.000642000 4970 0x1f0cb80 LOG GST_DEBUG gstinfo.c:1228:gst_debug_reset_threshold: category query matches pattern 0x4b98350 - gets set to level 5 0:00:00.000845000 4970 0x1f0cb80 LOG GST_DEBUG gstinfo.c:1228:gst_debug_reset_threshold: category GST_DATAFLOW matches pattern 0x4b98350 - gets set to level 5 0:00:00.000969000 4970 0x1f0cb80 LOG GST_DEBUG gstinfo.c:1228:gst_debug_reset_threshold: category GST_ELEMENT_FACTORY matches pattern 0x4b98350 - gets set to level 5 0:00:00.001002000 4970 0x1f0cb80 DEBUG default gstelement.c:278:gst_element_base_class_init: type GstElement : factory 0x0 0:00:00.001043000 4970 0x1f0cb80 LOG GST_DEBUG gstinfo.c:1228:gst_debug_reset_threshold: category GST_TYPEFIND matches pattern 0x4b98350 - gets set to level 5 0:00:00.001086000 4970 0x1f0cb80 LOG GST_DEBUG gstinfo.c:1228:gst_debug_reset_threshold: category bin matches pattern 0x4b98350 - gets set to level 5 0:00:00.001109000 4970 0x1f0cb80 DEBUG default gstelement.c:278:gst_element_base_class_init: type GstBin : factory 0x0 0:00:00.001167000 4970 0x1f0cb80 DEBUG bin gstbin.c:498:gst_bin_class_init: creating bin thread pool 0:00:00.001224000 4970 0x1f0cb80 LOG GST_DEBUG gstinfo.c:1228:gst_debug_reset_threshold: category task matches pattern 0x4b98350 - gets set to level 5 0:00:00.001243000 4970 0x1f0cb80 LOG GST_DEBUG gstinfo.c:1228:gst_debug_reset_threshold: category taskpool matches pattern 0x4b98350 - gets set to level 5 0:00:00.001319000 4970 0x1f0cb80 LOG GST_DEBUG gstinfo.c:1228:gst_debug_reset_threshold: category GST_URI matches pattern 0x4b98350 - gets set to level 5 0:00:00.001633000 4970 0x1f0cb80 INFO GST_INIT gstmessage.c:73:_gst_message_initialize: init messages 0:00:00.002144000 4970 0x1f0cb80 INFO GST_PLUGIN_LOADING gstplugin.c:348:_gst_plugin_initialize: registering 0 static plugins 0:00:00.002160000 4970 0x1f0cb80 LOG GST_PLUGIN_LOADING gstplugin.c:251:gst_plugin_register_static: attempting to load static plugin "staticelements" now... 0:00:00.002208000 4970 0x1f0cb80 LOG GST_PLUGIN_LOADING gstplugin.c:538:gst_plugin_register_func: plugin "(NULL)" looks good 0:00:00.002271000 4970 0x1f0cb80 LOG GST_ELEMENT_FACTORY gstelementfactory.c:247:gst_element_register:<bin> Created new elementfactory for type GstBin 0:00:00.002303000 4970 0x1f0cb80 DEBUG GST_REGISTRY gstregistry.c:544:gst_registry_add_feature:<registry0> adding feature 0x21ab090 (bin) 0:00:00.002317000 4970 0x1f0cb80 LOG GST_REGISTRY gstregistry.c:560:gst_registry_add_feature:<registry0> emitting feature-added for bin 0:00:00.002345000 4970 0x1f0cb80 LOG GST_DEBUG gstinfo.c:1228:gst_debug_reset_threshold: category pipeline matches pattern 0x4b98350 - gets set to level 5 0:00:00.002366000 4970 0x1f0cb80 LOG GST_ELEMENT_FACTORY gstelementfactory.c:247:gst_element_register:<pipeline> Created new elementfactory for type GstPipeline 0:00:00.002381000 4970 0x1f0cb80 DEBUG default gstelement.c:278:gst_element_base_class_init: type GstPipeline : factory 0x21ab120 0:00:00.002411000 4970 0x1f0cb80 DEBUG GST_REGISTRY gstregistry.c:544:gst_registry_add_feature:<registry0> adding feature 0x21ab120 (pipeline) 0:00:00.002424000 4970 0x1f0cb80 LOG GST_REGISTRY gstregistry.c:560:gst_registry_add_feature:<registry0> emitting feature-added for pipeline 0:00:00.002434000 4970 0x1f0cb80 LOG GST_PLUGIN_LOADING gstplugin.c:563:gst_plugin_register_func: plugin "(NULL)" initialised 0:00:00.002445000 4970 0x1f0cb80 INFO GST_PLUGIN_LOADING gstplugin.c:254:gst_plugin_register_static: registered static plugin "staticelements" 0:00:00.002455000 4970 0x1f0cb80 DEBUG GST_REGISTRY gstregistry.c:436:gst_registry_add_plugin:<registry0> adding plugin 0x21a4a40 for filename "(NULL)" 0:00:00.002466000 4970 0x1f0cb80 LOG GST_REGISTRY gstregistry.c:446:gst_registry_add_plugin:<registry0> emitting plugin-added for filename "(NULL)" 0:00:00.002476000 4970 0x1f0cb80 INFO GST_PLUGIN_LOADING gstplugin.c:256:gst_plugin_register_static: added static plugin "staticelements", result: 1 0:00:00.002493000 4970 0x1f0cb80 INFO GST_REGISTRY gstregistry.c:1572:ensure_current_registry: reading registry cache: /Users/jeremy/.gstreamer-0.10/registry.x86_64.bin 0:00:00.002617000 4970 0x1f0cb80 DEBUG GST_REGISTRY gstregistrybinary.c:544:gst_registry_binary_read_cache: File data at address 0x571c000 0:00:00.002639000 4970 0x1f0cb80 DEBUG GST_REGISTRY gstregistrybinary.c:455:gst_registry_binary_check_magic: Reading/casting for GstBinaryRegistryMagic at address 0x571c000 0:00:00.002655000 4970 0x1f0cb80 LOG GST_REGISTRY gstregistrychunks.c:866:_priv_gst_registry_chunks_load_global_header: Reading/casting for GstRegistryChunkGlobalHeader at 0x571c044 0:00:00.002675000 4970 0x1f0cb80 DEBUG GST_REGISTRY gstregistrybinary.c:586:gst_registry_binary_read_cache: reading binary registry 72(48)/340117 0:00:00.002689000 4970 0x1f0cb80 LOG GST_REGISTRY gstregistrychunks.c:763:_priv_gst_registry_chunks_load_plugin: Reading/casting for GstRegistryChunkPluginElement at address 0x571c048 0:00:00.002715000 4970 0x1f0cb80 LOG GST_REGISTRY gstregistrychunks.c:782:_priv_gst_registry_chunks_load_plugin: read strings for name='???J' 0:00:00.002727000 4970 0x1f0cb80 LOG GST_REGISTRY gstregistrychunks.c:783:_priv_gst_registry_chunks_load_plugin: desc.description='' 0:00:00.002736000 4970 0x1f0cb80 LOG GST_REGISTRY gstregistrychunks.c:784:_priv_gst_registry_chunks_load_plugin: filename='' 0:00:00.002746000 4970 0x1f0cb80 LOG GST_REGISTRY gstregistrychunks.c:785:_priv_gst_registry_chunks_load_plugin: desc.version='' 0:00:00.002755000 4970 0x1f0cb80 LOG GST_REGISTRY gstregistrychunks.c:786:_priv_gst_registry_chunks_load_plugin: desc.license='' 0:00:00.002764000 4970 0x1f0cb80 LOG GST_REGISTRY gstregistrychunks.c:787:_priv_gst_registry_chunks_load_plugin: desc.source='' 0:00:00.002774000 4970 0x1f0cb80 LOG GST_REGISTRY gstregistrychunks.c:788:_priv_gst_registry_chunks_load_plugin: desc.package='' 0:00:00.002783000 4970 0x1f0cb80 LOG GST_REGISTRY gstregistrychunks.c:789:_priv_gst_registry_chunks_load_plugin: desc.origin='' 0:00:00.002799000 4970 0x1f0cb80 WARN default gststructure.c:2086:gst_structure_from_string: Failed to parse structure string '' 0:00:00.002813000 4970 0x1f0cb80 DEBUG GST_REGISTRY gstregistry.c:436:gst_registry_add_plugin:<registry0> adding plugin 0x21a4ae0 for filename "" 0:00:00.002825000 4970 0x1f0cb80 LOG GST_REGISTRY gstregistry.c:446:gst_registry_add_plugin:<registry0> emitting plugin-added for filename "" 0:00:00.002836000 4970 0x1f0cb80 DEBUG GST_REGISTRY gstregistrychunks.c:807:_priv_gst_registry_chunks_load_plugin: Added plugin '???J' plugin with 0 features from binary registry 0:00:00.002850000 4970 0x1f0cb80 LOG GST_REGISTRY gstregistrychunks.c:709:gst_registry_chunks_load_plugin_dep:<plugin1> Unpacking GstRegistryChunkDep from 0x571c068 GLib-ERROR **: gmem.c:405: overflow allocating 1701668205*4 bytes aborting... /opt/local/lib/firefox-x11-standalone/run-mozilla.sh: line 131: 4970 Abort trap (core dumped) "$prog" ${1+"$@"} --- Thread 0 Crashed: Dispatch queue: com.apple.main-thread 0 libSystem.B.dylib 0x955ba176 __kill + 10 1 libSystem.B.dylib 0x955ba168 kill$UNIX2003 + 32 2 libSystem.B.dylib 0x9564c89d raise + 26 3 libxul.dylib 0x0002265c XRE_LockProfileDirectory + 4396 4 libSystem.B.dylib 0x955bf46b _sigtramp + 43 5 libSystem.B.dylib 0x955ba176 __kill + 10 6 libSystem.B.dylib 0x955ba168 kill$UNIX2003 + 32 7 libSystem.B.dylib 0x9564c89d raise + 26 8 libSystem.B.dylib 0x956629bc abort + 93 9 libglib-2.0.0.dylib 0x0186e243 g_logv + 611 10 libglib-2.0.0.dylib 0x0186e519 g_log + 41 11 libglib-2.0.0.dylib 0x0186cf14 g_malloc0_n + 116 12 libgstreamer-0.10.0.dylib 0x05660f94 gst_registry_chunks_load_plugin_dep_strv + 68 13 libgstreamer-0.10.0.dylib 0x0566121d gst_registry_chunks_load_plugin_dep + 141 14 libgstreamer-0.10.0.dylib 0x056633cd _priv_gst_registry_chunks_load_plugin + 3565 15 libgstreamer-0.10.0.dylib 0x0568cef7 gst_registry_binary_read_cache + 1159 16 libgstreamer-0.10.0.dylib 0x0565fe51 gst_update_registry + 1393 17 libgstreamer-0.10.0.dylib 0x0560babd init_post + 1277 18 libglib-2.0.0.dylib 0x01873513 g_option_context_parse + 595 19 libgstreamer-0.10.0.dylib 0x0560af8e gst_init_check + 158 20 libcanberra-gstreamer.so 0x05605392 gstreamer_driver_open + 146 21 libcanberra.0.dylib 0x055b7672 driver_open + 434 22 libcanberra.0.dylib 0x055af388 context_open_unlocked + 72 23 libcanberra.0.dylib 0x055afc18 ca_context_play_full + 344 24 libcanberra.0.dylib 0x055aff91 ca_context_play + 113 25 libxul.dylib 0x009d2e22 JSD_DebuggerOnForUser + 859522 26 libxul.dylib 0x00391cfe DumpJSEval + 3575358 27 libxul.dylib 0x003a026c DumpJSEval + 3634092 28 libxul.dylib 0x003a0ab9 DumpJSEval + 3636217 29 libxul.dylib 0x003a0b47 DumpJSEval + 3636359 30 libxul.dylib 0x00a8800c NS_GetComponentManager_P + 36316 31 libxul.dylib 0x00a4bf23 GetSecurityContext(JNIEnv_*, nsISecurityContext**) + 297667 32 libxul.dylib 0x009e6da0 JSD_DebuggerOnForUser + 941312 33 libxul.dylib 0x0085f4cf DumpJSEval + 8611343 34 libxul.dylib 0x0001c541 XRE_main + 12961 35 firefox-bin 0x00002be8 start + 360 36 firefox-bin 0x00002ab5 start + 53
Does this still happen with 0.10.32 ? There were some OSX-related fixes in the GstPoll pselect backend and the plugin scanner.
The issue persists in 0.10.32
Created attachment 179208 [details] 0.10.32 and firefox 3.6.13 Actually, it is failing differently now. With gstreamer 0.10.32 and firefox 3.6.13, I see the attached, and it no longer loops. It ends with: 0:00:00.011678000 37242 0x100609f80 LOG GST_PLUGIN_LOADING gstpluginloader.c:927:exchange_packets: Poll res = 2. 12 bytes pending for write 0:00:00.011686000 37242 0x100609f80 DEBUG GST_POLL gstpoll.c:1058:gst_poll_fd_has_error: 0x100825ad0: fd (fd:5, idx:2) 0:00:00.011694000 37242 0x100609f80 DEBUG GST_POLL gstpoll.c:1013:gst_poll_fd_has_closed: 0x100825ad0: fd (fd:5, idx:2) 0:00:00.011702000 37242 0x100609f80 DEBUG GST_POLL gstpoll.c:1092:gst_poll_fd_can_read_unlocked: 0x100825ad0: fd (fd:5, idx:2) Again, I stress that this may be due to architecture differences. gst-plugin-scanner is running as x86_64 while firefox is running as i386
(In reply to comment #14) > Again, I stress that this may be due to architecture differences. > gst-plugin-scanner is running as x86_64 while firefox is running as i386 Are you doing 'universal' builds of GStreamer ? Looks like the 32bit gstreamer core (the one called called/loaded from your 32bit firefox) is spawning the plugin-scanner in 64bit mode. Is the plugin-scanner also a universal executable (does it contain both 32/64bit code) ?
gstrteamer is built fat / universal and contains both i386 and x86_64 bits: $ file gst-plugin-scanner gst-plugin-scanner: Mach-O universal binary with 2 architectures gst-plugin-scanner (for architecture x86_64): Mach-O 64-bit executable x86_64 gst-plugin-scanner (for architecture i386): Mach-O executable i386 firefox, however, is not fat. firefox-3.6.13 is i386 only. When it execs gst-plugin-scanner, the 64bit version is execd. If I think gst-plugin-scanner to 32bit, firefox loads. So it is certainly an architecture matching issue.
(In reply to comment #16) > If I think gst-plugin-scanner to 32bit, firefox loads. If I thin gst-plugin-scanner to 32bit, firefox loads.
Once thinned to 32bit, my 64bit firefox4 build fails in a similar fashion, so that might be the easier test case for you: 1) build gstreamer fat 2) thin gst-plugin-scanner to i386 3) launch a 64bit app that uses gstreamer
Sounds like on OS/X we need some: #if defined (i386) launch "arch -i386 plugin-scanner..." #elif defined (x86_64) launch "arch -x86_64 plugin-scanner..." #endif
Renaming bug
Milestone changed? Can we get this fix committed please?
Created attachment 185678 [details] [review] changes suggested by Jan
Created attachment 185679 [details] [review] changes suggested by Jan
Review of attachment 185679 [details] [review]: Looks good to me. I assume it fixes your problem? I can't test, my MacOS/X box died.
Ok, committed this for now with cosmetic changes: commit 159cf687a1b63f334ecec5e0b1ea4cd1bc8e7537 Author: Jan Schmidt <thaytan@mad.scientist.com> Date: Mon Apr 11 11:29:00 2011 +0100 pluginloader: make sure gst-plugin-scanner is called with the right arch on OSX On OSX, GStreamer might be built as a 'fat/universal' binary containing both 32-bit and 64-bit code. We must take care that gst-plugin-scanner is executed with the same architecture as the GStreamer core, otherwise bad things may happen and core/scanner will not be able to communicate properly. Should fix issues with (32-bit) firefox using a 32-bit GStreamer core which then spawns a 'universal' gst-plugin-scanner binary which gets run in 64-bit mode, causing 100% cpu usage / busy loops or just hanging firefox until killed. https://bugzilla.gnome.org/show_bug.cgi?id=615357 Would be great if someone could confirm that it actually fixes the issue for them.
Created attachment 185690 [details] [review] pluginloader: make sure gst-plugin-scanner is called with the right arch on OSX
/usr/bin/arch has always existed on OS X, but on older 10.x it merely reports arch data and cannot be used as a wrapper to set the arch. Hardcoding its use here limits backward portability (either to compile, or to build on new that is still usable on old). I think it changed to the wrapper behavior as of 10.5, so certainly reasonable to abandon the ancient 10.4 and earlier, but might want to document this limitation. On 10.4, there wasn't really the same idea of multiarch (each CPU did not have multiple modes), so could maybe have runtime check for kernel version to control whether to use the wrapper.
Daniel: what would you recommend? What's the best way to detect this at run-time?
Here's a snippet of code that I've used for runtime checks. There may be something better, but this works for me: #define __OS_MAJOR_10_4 8 #define __OS_MAJOR_10_5 9 #define __OS_MAJOR_10_6 10 #define __OS_MAJOR_10_7 11 static int __os_major_version; void some_initializer() { if (sysctlbyname("kern.osrelease", buf, &buf_n, NULL, 0) == -1) { perror("sysctl"); __os_major_version = __OS_MAJOR_10_6; // Set to something reasonable } else { for(p=buf; *p && *p != '.'; p++); *p = '\0'; __os_major_version = atoi(buf); } }
sysctl's interface always confuses the heck out of me, so I use uname... #include <stdlib.h> #include <sys/utsname.h> int usr_bin_arch_wraps(void) { struct utsname data; int major; // kernel major-version uname(&data); major=strtod(data.release, NULL); /* check for OS X >= 10.5 (darwin kernel 9.0) */ if(major >=9) return(1); return(0); } Looks like we're both taking the same approach to kernel-version testing.
Thank you both for the version testing code. Committed this now, hope it works right: commit f660536eb341767fbef0ccf1bf1139e2b4ce749c Author: Tim-Philipp Müller <tim.muller@collabora.co.uk> Date: Fri Apr 15 20:58:51 2011 +0100 pluginloader: only run gst-plugin-scanner with /usr/bin/arch wrapper on OS X >= 10.5 Based on patch by: Daniel Macks <dmacks@netspace.org> Earlier versions of OSX don't support proper multiarch and trying to use /usr/bin/arch -foo with those versions would just break things. https://bugzilla.gnome.org/show_bug.cgi?id=615357 Please re-open if I screwed up, thanks!
I am seeing users report this issue on my Banshee 2.3.2 pre OS X image. It is built against GStreamer 0.10.35 which should have the changes listed above using bockbuild. http://ompldr.org/vYmRmZg/Banshee.dmg https://twitter.com/#!/MarcoDahms/status/138346210955247617
The user in question just confirmed that a builds against .35 and .34 exhibit the problem, however a build against .32 (.33 shipped in testing for lack of time) does not. Thus for now this problem stops me rom bumping Banshee OS X builds beyond .32
Someone with an OS X setup that exhibits this issue needs to investigate this.
After a bit of bisecting to figure out where exactly the problem started, I made a build of 0.35 with the following commits reverted and my affected user now reports that Banshee starting up no longer triggers the issue: (Unsurprisingly these are all the post .32 commits to the pluginloader) http://cgit.freedesktop.org/gstreamer/gstreamer/patch/?id=f660536eb341767fbef0ccf1bf1139e2b4ce749c http://cgit.freedesktop.org/gstreamer/gstreamer/patch/?id=918a62abcf7ae44b0bc84d57742d2f759e0d8ed6 http://cgit.freedesktop.org/gstreamer/gstreamer/patch/?id=159cf687a1b63f334ecec5e0b1ea4cd1bc8e7537
My understanding is that these commits did actually fix some issues for other people, and they also seem like the right thing to do to me, so I'm reluctant to just revert them. I would first like to understand what's going on here. The twitter post you mentioned refers to a pastebinned log that contains this at the end: arch: /Users/davidnielsen/Projekter/bockbuild/profiles/banshee/build-root/_install/libexec/gstreamer-0.10/gst-plugin-scanner isn't executable Maybe this is just a packaging issue? Or maybe this issue always existed, but the error handling (fallback to scanning in the main program instead of using an external plugin scanner) doesn't work? A full GST_DEBUG=*:5 log might be useful.
By the way, there's also an autoconf bug that might be related, see bug #664695. The config.log from the GStreamer build might be good to have too in addition to the GST_DEBUG log.
I build Gstreamer using bockbuild, there is nothing special about it so I doubt it is a packaging bug. I am more tempted to blame autoconf for not doing things right (building 32bit build on 64bit might confuse it despite being specifically told to use -m32 -arch i386). I have requested Marco Dahms to provide the requested information.
Hey. David gave me a testversion of Banshee for osx. It did not start. Here is the debug log for this version. <code> Appears to be first run of this application bundle. Application bundle has moved. Adjusting bundle... [Info 19:28:09.432] Running Banshee 2.3.2: [git-checkout (darwin11.2.0, x86_64) @ 2011-12-09 22:36:44 BRST] [1 Debug 19:28:10.302] Initializing GTK [1 Debug 19:28:14.541] Post-Initializing GTK [1 Debug 19:28:14.667] Configuration client extension loaded (Banshee.Configuration.XmlConfigurationClient) [1 Warn 19:28:14.775] DBus support could not be started. Disabling for this session. - System.DllNotFoundException: libc.so.6 (in `dbus-sharp') at (wrapper managed-to-native) DBus.Unix.UnixSocket:socket (int,int,int) at DBus.Unix.UnixSocket..ctor () [0x00006] in /Users/gnomeuser/Projects/bockbuild/profiles/banshee/build-root/dbus-sharp-0.7.0/_build/dbus-sharp-0.7.0/src/Unix.cs:286 at DBus.Transports.UnixNativeTransport.OpenUnix (System.String path) [0x00007] in /Users/gnomeuser/Projects/bockbuild/profiles/banshee/build-root/dbus-sharp-0.7.0/_build/dbus-sharp-0.7.0/src/UnixNativeTransport.cs:129 at DBus.Transports.UnixNativeTransport.Open (System.String path, Boolean abstract) [0x0002e] in /Users/gnomeuser/Projects/bockbuild/profiles/banshee/build-root/dbus-sharp-0.7.0/_build/dbus-sharp-0.7.0/src/UnixNativeTransport.cs:36 at DBus.Transports.UnixTransport.Open (DBus.AddressEntry entry) [0x00047] in /Users/gnomeuser/Projects/bockbuild/profiles/banshee/build-root/dbus-sharp-0.7.0/_build/dbus-sharp-0.7.0/src/UnixTransport.cs:24 at DBus.Transports.Transport.Create (DBus.AddressEntry entry) [0x00076] in /Users/gnomeuser/Projects/bockbuild/profiles/banshee/build-root/dbus-sharp-0.7.0/_build/dbus-sharp-0.7.0/src/Transport.cs:27 at DBus.Connection.OpenPrivate (System.String address) [0x0003b] in /Users/gnomeuser/Projects/bockbuild/profiles/banshee/build-root/dbus-sharp-0.7.0/_build/dbus-sharp-0.7.0/src/Connection.cs:88 at DBus.Connection..ctor (System.String address) [0x00048] in /Users/gnomeuser/Projects/bockbuild/profiles/banshee/build-root/dbus-sharp-0.7.0/_build/dbus-sharp-0.7.0/src/Connection.cs:39 at DBus.Bus..ctor (System.String address) [0x00000] in <filename unknown>:0 at DBus.Bus.Open (System.String address) [0x00025] in /Users/gnomeuser/Projects/bockbuild/profiles/banshee/build-root/dbus-sharp-0.7.0/_build/dbus-sharp-0.7.0/src/Bus.cs:84 at DBus.Bus.get_System () [0x0002d] in /Users/gnomeuser/Projects/bockbuild/profiles/banshee/build-root/dbus-sharp-0.7.0/_build/dbus-sharp-0.7.0/src/Bus.cs:22 System.Exception: Unable to open the system message bus. (in `dbus-sharp') at DBus.Bus.get_System () [0x00042] in /Users/gnomeuser/Projects/bockbuild/profiles/banshee/build-root/dbus-sharp-0.7.0/_build/dbus-sharp-0.7.0/src/Bus.cs:24 at DBus.BusG.Init () [0x0000b] in /Users/gnomeuser/Projects/bockbuild/profiles/banshee/build-root/dbus-sharp-glib-0.5.0/_build/dbus-sharp-glib-0.5.0/src/GLib.cs:21 at Banshee.ServiceStack.DBusConnection.Connect (System.String serviceName, Boolean init) [0x0000c] in /Users/gnomeuser/Projects/banshee/src/Core/Banshee.Services/Banshee.ServiceStack/DBusConnection.cs:132 at Banshee.ServiceStack.DBusConnection.Connect (System.String serviceName) [0x00012] in /Users/gnomeuser/Projects/banshee/src/Core/Banshee.Services/Banshee.ServiceStack/DBusConnection.cs:106 [1 Debug 19:28:14.906] Core service started (DBusServiceManager, 0,002517) [1 Debug 19:28:14.910] Core service started (DBusCommandService, 0,002967) [1 Debug 19:28:15.059] Opened SQLite (version 3.7.9) connection to /Users/marcodahms/.config/banshee-1/banshee.db [1 Debug 19:28:15.060] Core service started (DbConnection, 0,149368) [1 Debug 19:28:15.073] Database version 45 is up to date [1 Debug 19:28:15.215] Core service started (PreferenceService, 0,11687) [1 Warn 19:28:15.222] Verbindung zum Netzwerk-Manager oder Wicd konnte nicht hergestellt werden - Eine verfügbare, arbeitende Netzwerkverbindung wird angenommen [1 Debug 19:28:15.222] Core service started (Network, 0,007063) [1 Debug 19:28:15.224] Core service started (SourceManager, 0,002001) [1 Debug 19:28:15.234] Core service started (MediaProfileManager, 0,000476) [1 Debug 19:28:15.246] Core service started (PlayerEngine, 0,012142) [1 Debug 19:28:15.920] Core service started (PlaybackController, 0,003207) [1 Debug 19:28:15.930] Starting - Startup Job [1 Debug 19:28:15.931] Core service started (JobScheduler, 0,010389) [1 Debug 19:28:15.943] IO provider extension loaded (Banshee.IO.Unix.Provider) [1 Warn 19:28:15.945] Service `Banshee.Hardware.HardwareManager' not started: No HardwareManager extensions could be loaded. Hardware support will be disabled. [1 Warn 19:28:15.996] Caught an exception - System.Exception: No HardwareManager extensions could be loaded. Hardware support will be disabled. (in `Banshee.Services') at Banshee.Hardware.HardwareManager..ctor () [0x00121] in /Users/gnomeuser/Projects/banshee/src/Core/Banshee.Services/Banshee.Hardware/HardwareManager.cs:74 at (wrapper managed-to-native) System.Reflection.MonoCMethod:InternalInvoke (System.Reflection.MonoCMethod,object,object[],System.Exception&) at System.Reflection.MonoCMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00119] in /Users/gnomeuser/Projects/bockbuild/profiles/banshee/build-root/mono-2.10.7/_build/mono-2.10.7/mcs/class/corlib/System.Reflection/MonoMethod.cs:526 [1 Debug 19:28:15.998] Core service started (CollectionIndexerService, 0,002183) [1 Debug 19:28:16.000] Core service started (SaveTrackMetadataService, 0,001989) [1 Debug 19:28:16.249] Adding icon theme search path: /Applications/Banshee.app/Contents/Resources/share/banshee/icons [1 Debug 19:28:16.251] Core service started (GtkElementsService, 0,250892) [1 Debug 19:28:16.311] Core service started (InterfaceActionService, 0,059243) [1 Debug 19:28:16.860] Extension actions loaded: MetadataFixActions [1 Debug 19:28:16.888] Album artwork path set to /Users/marcodahms/.cache/media-art [1 Debug 19:28:16.968] Core service started (ArtworkManager, 0,107036) [1 Debug 19:28:16.968] Core service started (BookmarksService, 0,000317) [1 Debug 19:28:17.931] Adding context page lastfm-recommendations [1 Debug 19:28:18.461] Constructed Nereid interface: 1,410805 [1 Debug 19:28:18.590] Creating new surface cache for 90px images, capped at 0,77 MiB (25 items) [1 Debug 19:28:18.731] Core service started (NereidPlayerInterface, 1,724796) [1 Debug 19:28:18.744] Extension service started (AmazonMp3DownloaderService, 0,011959) [1 Debug 19:28:18.762] Audioscrobbler state: connected [1 Debug 19:28:18.765] Extension service started (AudioscrobblerService, 0,019974) [1 Debug 19:28:18.779] Extension service started (LastfmStreamingService, 0,014492) [1 Debug 19:28:18.854] Extension service started (OsxService, 0,074971) [1 Debug 19:28:18.917] Extension service started (EmusicService, 0,062419) arch: /Users/gnomeuser/Projects/bockbuild/profiles/banshee/build-root/_install/libexec/gstreamer-0.10/gst-plugin-scanner isn't executable </code>
uhm... chmod 755 /Users/gnomeuser/Projects/bockbuild/profiles/banshee/build-root/_install/libexec/gstreamer-0.10/gst-plugin-scanner ${prefix}/libexec/gstreamer-0.10/gst-plugin-scanner is executable here with gstreamer 0.10.35. The only "odd" think you mention is your bockbuild. I have no idea what that is, but it's likely that bockbuild or your packaging is to blame. Chance are you installed your package, noticed it didn't work, then installed gstreamer by hand and noticed that it did work. It's working because of that file being executable and has nothing to do with the code. I don't think this is a gstreamer bug.
(ie: Please move this back to Resolved/Fixed)
Closing as requested. Please provide requested debug logs and the output of ls -l /Users/gnomeuser/Projects/bockbuild/profiles/banshee/build-root/_install/libexec/gstreamer-0.10/gst-plugin-scanner before re-opening again.