GNOME Bugzilla – Bug 661177
gnome-control-center crashed with SIGSEGV in default_adapter_powered_changed()
Last modified: 2011-10-21 13:21:18 UTC
this report has been filed here: https://bugs.launchpad.net/ubuntu/+source/gnome-bluetooth/+bug/828436 "Trying to add a new bluetooth device" Package: gnome-control-center 1:3.2.0-0ubuntu6 ".
+ Trace 228708
Thread 1 (Thread 0x7f0b38719940 (LWP 14583))
+ Trace 228772
That's in NetworkManager.
We'd need to get ~/.xsession-errors here too, if this happens again. Otherwise there's no context and we can't figure out why the crash happened.
I can reproduce a similar bug (maybe it's the same core issue) very easily:
+ Trace 228781
Steps to reproduce: 1) Disable bluetooth with hardware switch 2) Start g-c-c and go to bluetooth panel 3) Enable bluetooth with hardware switch 4) (gnome-bluetooth bug) See that the panel still sees bluetooth as disabled with no way to enable it; use the gnome-shell icon to disable and re-enable bluetooth 5) (not sure if it's needed) go to a phone device that can be used by NM 6) use hardware switch to disable bluetooth => crash I have this in my ~/.xsession-errors: Agent unregistration failed: Method "UnregisterAgent" with signature "o" on interface "org.bluez.Adapter" doesn't exist 'dbus-glib-error-quark'
I think the issue is that the the dbus object is gone when I disable bluetooth with the hardware switch, so the calling a method on the org.bluez.Adapter interface can't work anymore.
(In reply to comment #4) > I think the issue is that the the dbus object is gone when I disable bluetooth > with the hardware switch, so the calling a method on the org.bluez.Adapter > interface can't work anymore. So, looking at the code, and based on the stack trace... this is completely unrelated to my error in ~/.xsession-errors. So comment 4 is just wrong :-) It just looks like a property of the BluetoothClient is changed, but when we get to the signal handler, we've already unreferenced the BluetoothClient.
Created attachment 198936 [details] [review] Fix the issue Confirming that disconnecting the signals fix the crash. I'm not really happy about doing it this way -- ideally, we wouldn't even get the signals after having unref'ed the object. But I'm unsure why this is happening in the first place...
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find. *** This bug has been marked as a duplicate of bug 654172 ***
This one is not a duplicate :-)
(In reply to comment #8) > This one is not a duplicate :-) Indeed, my mistake.
Hmm. If info->bt_client is getting destroyed correctly it shouldn't be emitting any signals. But AFAICT we don't ref/unref it anywhere except when it's created, and when it's destroyed. So I can't really see what's going on here. In any case, patch applied, thanks! bfb603de56c9be28594c637b7030d0c43be353ef (master) (also applied to 0.8.x)
(In reply to comment #10) > Hmm. If info->bt_client is getting destroyed correctly Nope, it's getting unreffed. And as it's a singleton, you need to disconnect from those manually. > it shouldn't be > emitting any signals. But AFAICT we don't ref/unref it anywhere except when > it's created, and when it's destroyed. So I can't really see what's going on > here. In any case, patch applied, thanks! > > bfb603de56c9be28594c637b7030d0c43be353ef (master) > (also applied to 0.8.x) I'm not sure that patch isn't breaking other things though. Let's reopen, and I'll see about cleaning this up.
Created attachment 199638 [details] [review] Another tighter fix
I'm being stupid though, and missed the "info" part of the disconnection. Feel free to apply this patch or drop it, don't think it's necessary.