GNOME Bugzilla – Bug 662309
banshee crashes silently, periodically in ZeroConf / Avahi code.
Last modified: 2011-11-28 15:17:03 UTC
Running banshee 2.2.0 that ships with 64 bit Ubuntu 11.10, it crashes every few hours. I ran it from the console (banshee --debug) and when it crashed, it spat this message: Unhandled Exception: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.NullReferenceException: Object reference not set to an instance of an object at Mono.Zeroconf.Providers.AvahiDBus.BrowseService.DisposeResolver () [0x00000] in <filename unknown>:0 at Mono.Zeroconf.Providers.AvahiDBus.BrowseService.Dispose () [0x00000] in <filename unknown>:0 at Mono.Zeroconf.Providers.AvahiDBus.ServiceBrowser.OnItemRemove (Int32 interface, Protocol protocol, System.String name, System.String type, System.String domain, LookupResultFlags flags) [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 NDesk.DBus.Connection.HandleSignal (NDesk.DBus.Message msg) [0x00000] in <filename unknown>:0 at NDesk.DBus.Connection.DispatchSignals () [0x00000] in <filename unknown>:0 at NDesk.DBus.Connection.Iterate () [0x00000] in <filename unknown>:0 at Mono.Zeroconf.Providers.AvahiDBus.DBusManager.IterateThread (System.Object o) [0x00000] in <filename unknown>:0 It was paused at the time, but it also crashes sometimes in the middle of playing a track.
*** Bug 662632 has been marked as a duplicate of this bug. ***
I guess best thing to do is migrate MonoZeroconf to dbus-sharp. Wasn't someone working on this already? (IIRC from what I read on IRC)
I did try. But the resultant mono-zeroconf didn't resolve anything at all. =\
Created attachment 199918 [details] [review] Rough patch porting mono-zeroconf to dbus# Here's what I came up with. It compiles, but apparently doesn't work, based on what I've heard on IRC.
Ah, well, good work. I guess it's still better to have this bug in dbus-sharp than in NDeskDbus. Is there a maintainer that can approve that patch to Mono.Zeroconf? Did you do a pull request?
Nope, I couldn't find an upstream to push the patch to. Same goes for notify-sharp which I just made a patch for earlier today.
Could anyone who is experiencing the bug confirm that disabling the DAAP extension fixes the issue ? FYI, hyperair's pull request is at https://github.com/mono/Mono.Zeroconf/pull/5 Does it help with this issue ?
Someone confirmed that disabling DAAP fixes the issue on IRC. The same person confirmed that my patch caused the DAAP extension to not detect any servers.
I haven't seen this crash anymore after disabling DAAP.
Braindump: A certain someone bundled NDesk.DBus *and modified* it in Mono.Zeroconf. TrapSignals and UntrapSignals which I removed from Mono.Zeroconf code was *never* there in NDesk.DBus in the first place. https://github.com/mono/Mono.Zeroconf/commit/3e2358e67a398b65fe1385446d889c75f5525392 for more details. Does anyone know what I should do from here on out? Bundle another DBus# and patch TrapSignals in again?
Okay, it looks like the signals are coming in between the ServiceBrowserNew call and adding event handlers in ServiceBrowser.cs, which is why TrapSignals is needed. avahi-client on the other hand uses a filter on DBus messages to get these signals and pass them to the respective objects. It looks like a pretty ugly solution. I would try duplicating this in Mono.Zeroconf but it looks like DBus# is incapable of filtering just yet.
After several attempts at killing a DAAP server (Tangerine) while Banshee is running, I was not able to reproduce the crash. Could someone able to reproduce this issue provide a stack trace with line numbers ? Another idea to investigate this: add logs in the 2 event handlers that end up calling BrowseService.DisposeResolver (BrowseService.OnResolveFailure and ServiceBrowser.OnItemRemove). Maybe they are triggered at the same time ? Although there are locks in place, so it shouldn't be a problem, but you never know...
Created attachment 200842 [details] New Mono.Zeroconf trace Looks like there's a reentrant Dispose() here, which is why the locking isn't working as it should.
A workaround would be to take a local reference to resolver in the DisposeResolver() function, and nullify the class's resolver reference before doing the cleanup. This could very well be a NDesk.DBus bug though. I'm not sure if NDesk.DBus is supposed to be able to dispatch signals while removing signal handlers.
Hmm, this reminded me of another weird dbus-related bug, which was caused by two races in NDesk.DBus : bug #627441. The two patches for dbus-sharp are : http://github.com/mono/dbus-sharp/commit/84f2126 http://github.com/garuma/dbus-sharp/commit/055982 Could try to apply them to the in-tree copy of NDesk.DBus inside Mono.ZeroConf, to see if it helps ?
I can't find https://github.com/garuma/dbus-sharp/commit/055982 in my dbus-sharp tree even after fetching from that tree. Is that commit possibly unreachable/rebased out?
Hmm, the patches don't apply on NDesk.DBus. I'm going to try isolating the TrapSignals change (hopefully that's all abock did) to DBus# and seeing if that works.
Created attachment 200860 [details] Mono.Zeroconf trace with DBus# Here's a trace after porting to a patched DBus# (from garuma's improved branch). It looks more or less the same as NDesk.DBus, so either DBus# is meant to behave like that, or the bug is still present.
Well I think we've more or less figured out that this bug doesn't belong to Banshee, so could a maintainer close this as NOTGNOME, please? Thanks for all the help in debugging this issue! For those interested:- - https://github.com/mono/Mono.Zeroconf/pull/6 has a fix/workaround for this crasher. - The DBus# port can wait until DBus# gains TrapSignals/UntrapSignals, as shown in https://github.com/mono/dbus-sharp/pull/23, because continuing to bundle DBus# is not nice. - I'm assuming that NDesk.DBus/DBus# is not wrong in dispatching more signals while attempting to remove the signal handler.
Closing as NOTGNOME, as the problem is with Mono.Zeroconf (see previous comment).
*** Bug 663388 has been marked as a duplicate of this bug. ***
*** Bug 652161 has been marked as a duplicate of this bug. ***
*** Bug 664089 has been marked as a duplicate of this bug. ***
*** Bug 664686 has been marked as a duplicate of this bug. ***