GNOME Bugzilla – Bug 659841
Hang when GConf can't be called(?)
Last modified: 2011-11-15 23:58:53 UTC
I don't really have much insight into why this would happen but it's started hitting me and another user quite frequently. I'm forwarding his bug report from Launchpad. https://bugs.launchpad.net/ubuntu/+source/banshee/+bug/854845 (happens on 2.2.0 too) Report follows -------------- Banshee randomly crashes on me. It happens a lot when the system is busy (i.e. during an apt-get upgrade) or when playing something from one playlist, then double-clicking on another ("hard") playlist. Banshee just hangs, and eats 400% CPU. Tail of log with -SIGQUIT traces at the end https://launchpadlibrarian.net/80635036/log Full --debug output https://launchpadlibrarian.net/80520542/banshee.log with additional messages dumped on STDERR [di 18:50] :) martijn@martijn-desktop:~$ banshee --debug 2>&1 > banshee.log (Banshee:25404): Gtk-WARNING **: Kan themamodule niet vinden in modulepad: ‘pixmap’, (Banshee:25404): Gtk-WARNING **: Kan themamodule niet vinden in modulepad: ‘pixmap’, (Banshee:25404): Gtk-WARNING **: Kan themamodule niet vinden in modulepad: ‘pixmap’, (Banshee:25404): Gtk-WARNING **: Kan themamodule niet vinden in modulepad: ‘pixmap’, (Banshee:25404): libsoup-WARNING **: No feature manager for feature of type 'U1RequestChrome' Exception in Gtk# callback delegate Note: Applications can use GLib.ExceptionManager.UnhandledException to handle the exception. System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> GLib.GException: Er kan geen contact worden gemaakt met de configuratieserver: D-BUS-fout: Method "Set" with signature "s(ii)" on interface "org.gnome.GConf.Database" doesn't exist at GConf.Client.SetValue (System.String key, GConf.Value val) [0x00000] in <filename unknown>:0 at GConf.ClientBase.Set (System.String key, System.Object val) [0x00000] in <filename unknown>:0 at Banshee.GnomeBackend.GConfConfigurationClient.Set[Int32] (System.String namespace, System.String key, Int32 value) [0x00000] in <filename unknown>:0 at Banshee.Configuration.ConfigurationClient.Set[Int32] (System.String namespace, System.String key, Int32 value) [0x00000] in <filename unknown>:0 at Banshee.Configuration.ConfigurationClient.Set[Int32] (SchemaEntry`1 entry, Int32 value) [0x00000] in <filename unknown>:0 at Banshee.Configuration.SchemaEntry`1[System.Int32].Set (Int32 value) [0x00000] in <filename unknown>:0 at Nereid.PlayerInterface.<ConnectEvents>m__5 (System.Object , Gtk.SizeRequestedArgs ) [0x00000] in <filename unknown>:0 at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (System.Reflection.MonoMethod,object,object[],System.Exception&) at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] in <filename unknown>:0 --- End of inner exception stack trace --- at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] in <filename unknown>:0 at System.Reflection.MethodBase.Invoke (System.Object obj, System.Object[] parameters) [0x00000] in <filename unknown>:0 at System.Delegate.DynamicInvokeImpl (System.Object[] args) [0x00000] in <filename unknown>:0 at System.MulticastDelegate.DynamicInvokeImpl (System.Object[] args) [0x00000] in <filename unknown>:0 at System.Delegate.DynamicInvoke (System.Object[] args) [0x00000] in <filename unknown>:0 at GLib.Signal.ClosureInvokedCB (System.Object o, GLib.ClosureInvokedArgs args) [0x00000] in <filename unknown>:0 at GLib.SignalClosure.Invoke (GLib.ClosureInvokedArgs args) [0x00000] in <filename unknown>:0 at GLib.SignalClosure.MarshalCallback (IntPtr raw_closure, IntPtr return_val, UInt32 n_param_vals, IntPtr param_values, IntPtr invocation_hint, IntPtr marshal_data) [0x00000] in <filename unknown>:0 at GLib.ExceptionManager.RaiseUnhandledException(System.Exception e, Boolean is_terminal) at GLib.SignalClosure.MarshalCallback(IntPtr raw_closure, IntPtr return_val, UInt32 n_param_vals, IntPtr param_values, IntPtr invocation_hint, IntPtr marshal_data) at Gtk.Application.gtk_main() at Gtk.Application.Run() at Banshee.Gui.GtkBaseClient.Run() at Banshee.Gui.GtkBaseClient.Startup() at Hyena.Gui.CleanRoomStartup.Startup(Hyena.Gui.StartupInvocationHandler startup) at Banshee.Gui.GtkBaseClient.Startup() at Banshee.Gui.GtkBaseClient.Startup(System.String[] args) at Nereid.Client.Main(System.String[] args) at System.AppDomain.ExecuteAssembly(System.AppDomain , System.Reflection.Assembly , System.String[] ) at System.AppDomain.ExecuteAssemblyInternal(System.Reflection.Assembly a, System.String[] args) at System.AppDomain.ExecuteAssembly(System.String assemblyFile, System.Security.Policy.Evidence assemblySecurity, System.String[] args) at System.AppDomain.ExecuteAssembly(System.String assemblyFile) at Booter.Booter.BootClient(System.String clientName) at Booter.Booter.Main()
On the advice of knocte, I ran with --disable-dbus. Seems it is still used indirectly though, by the GConf backend. Here's my log.
Created attachment 197274 [details] banshee log
More information. Sometimes package updates restart the gconfd-2 process like so kill -s HUP `pidof gconfd-2` >/dev/null 2>&1 and it seems this is the cause of the hang. Banshee should be able to handle the short periods when the gconf daemon is unavailable.
Even more information. I couldn't reproduce this with gconf 2.32.4 but upon upgrading to 3.2.0 I could again.
*** Bug 660398 has been marked as a duplicate of this bug. ***
Looks like bug 659835
(In reply to comment #6) > Looks like bug 659835 I think it is a dependency.
*** Bug 662223 has been marked as a duplicate of this bug. ***
*** Bug 662137 has been marked as a duplicate of this bug. ***
Can someone test with a new gconf that includes fix for bug 659835? As Chow says on IRC: hyperair> but is GConfSomething.Set supposed to be able to fail? hyperair> i think banshee should still try to stay alive rather than going berserk and eating up the CPU Banshee should still be more robust against a buggy gconf. But if the new gconf works, we can mark this bug as minor instead of major.
Created attachment 200155 [details] [review] Patch to move over to TrySet Okay, here's a little patch which works. One issue is that once GConf screws over, there's no coming back. I've dug around inside libgconf's code, and gconf-sharp's code, and the only way I can see us recovering from the issue is to somehow reinitialize the GConf.Engine. Unfortunately, reinitializing the GConf.Engine would require disposing all GConf.Clients in existence, as well as the gconf# copy in GConf.Engine.Default but GConf.Client doesn't implement IDisposable, or inherit from Glib.Object so we can't go about disposing it (unless I'm mistaken). Also, GConf.Engine.Default doesn't support getting a new default engine, so we'll end up just using the old disposed object, and segfault. Wonderful. This leaves manually DllImporting and poking at the gconf functions ourselves, but that doesn't work out so well either. GConf# doesn't allow us to access the raw pointer for that, so it's all or nothing. In a nutshell, I think it's best to just keep Banshee alive and not chewing up the CPU when GConf goes berserk. All further Set/Get things will fail. Incidentally, for anyone who's interested in testing this out, make sure you're running gconf using the DBus transport, and then issue killall -HUP gconfd-2.
I was able to reproduce the problem with gconf 3.2.0, using the instructions given above. But after installing gconf 3.2.2 (includes the fix for bug #659835), which is currently in oneiric-proposed, the issue doesn't happen anymore. So I'm not sure we need to apply this fix. I'll try to come up with something less invasive, maybe just a try/catch in GConfConfigurationClient.Set()
This problem has been fixed in our software repository. The fix will go into the next software release. Thank you for your bug report. I've committed the less invasive fix : http://git.gnome.org/browse/banshee/commit/?id=4ecc455 I'll be committing the fix to the stable-2.2 branch too.
*** Bug 658293 has been marked as a duplicate of this bug. ***
*** Bug 664156 has been marked as a duplicate of this bug. ***