GNOME Bugzilla – Bug 681456
Extra config widgets destroyed and recreated when Bluez device properties change
Last modified: 2012-09-07 12:32:31 UTC
During the NM plugin's DUN setup, the device's rfcomm service is started, which causes a the device to become Connected. That triggers the widget being destroyed by cc_bluetooth_panel_update_properties(). Backtraces of this happening twice, once when Connected -> TRUE, and the second time when Connected -> FALSE. Starting program: /usr/bin/gnome-control-center bluetooth [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". [New Thread 0x7fffe64bd700 (LWP 24012)] [New Thread 0x7fffe58a9700 (LWP 24013)] ^Y[Thread 0x7fffe58a9700 (LWP 24013) exited] ** Message: has_config_widget 00:XX:XX:XX:XX:66 DialupNetworking ** Message: has_config_widget 00:XX:XX:XX:XX:66 OBEXObjectPush ** Message: has_config_widget 00:XX:XX:XX:XX:66 OBEXFileTransfer ** Message: has_config_widget 00:XX:XX:XX:XX:66 AudioSource ** Message: has_config_widget 00:XX:XX:XX:XX:66 A/V_RemoteControlTarget ** Message: has_config_widget 00:XX:XX:XX:XX:66 A/V_RemoteControl ** Message: has_config_widget 00:XX:XX:XX:XX:66 Headset_-_AG ** Message: has_config_widget 00:XX:XX:XX:XX:66 HandsfreeAudioGateway ** Message: has_config_widget 00:XX:XX:XX:XX:66 Phonebook_Access_-_PSE ** Message: has_config_widget 00:XX:XX:XX:XX:66 DialupNetworking ** Message: has_config_widget 00:XX:XX:XX:XX:66 OBEXObjectPush ** Message: has_config_widget 00:XX:XX:XX:XX:66 OBEXFileTransfer ** Message: has_config_widget 00:XX:XX:XX:XX:66 AudioSource ** Message: has_config_widget 00:XX:XX:XX:XX:66 A/V_RemoteControlTarget ** Message: has_config_widget 00:XX:XX:XX:XX:66 A/V_RemoteControl ** Message: has_config_widget 00:XX:XX:XX:XX:66 Headset_-_AG ** Message: has_config_widget 00:XX:XX:XX:XX:66 HandsfreeAudioGateway ** Message: has_config_widget 00:XX:XX:XX:XX:66 Phonebook_Access_-_PSE ** Message: Default Bluetooth adapter is powered ** Message: dun_start: starting DUN device discovery... ** Message: Detecting phone configuration... ** Message: dun_start: calling Connect... ** Message: dun_start: waiting for Connect success... Breakpoint 1, widget_info_destroy (data=0x9d2020) at bt-widget.c:190 190 { (gdb) bt
+ Trace 230638
Continuing. ** Message: widget_info_destroy: NM Bluetooth widget info being destroyed ** Message: has_config_widget 00:XX:XX:XX:XX:66 DialupNetworking ** Message: has_config_widget 00:XX:XX:XX:XX:66 OBEXObjectPush ** Message: has_config_widget 00:XX:XX:XX:XX:66 OBEXFileTransfer ** Message: has_config_widget 00:XX:XX:XX:XX:66 AudioSource ** Message: has_config_widget 00:XX:XX:XX:XX:66 A/V_RemoteControlTarget ** Message: has_config_widget 00:XX:XX:XX:XX:66 A/V_RemoteControl ** Message: has_config_widget 00:XX:XX:XX:XX:66 Headset_-_AG ** Message: has_config_widget 00:XX:XX:XX:XX:66 HandsfreeAudioGateway ** Message: has_config_widget 00:XX:XX:XX:XX:66 Phonebook_Access_-_PSE ** Message: has_config_widget 00:XX:XX:XX:XX:66 DialupNetworking ** Message: has_config_widget 00:XX:XX:XX:XX:66 OBEXObjectPush ** Message: has_config_widget 00:XX:XX:XX:XX:66 OBEXFileTransfer ** Message: has_config_widget 00:XX:XX:XX:XX:66 AudioSource ** Message: has_config_widget 00:XX:XX:XX:XX:66 A/V_RemoteControlTarget ** Message: has_config_widget 00:XX:XX:XX:XX:66 A/V_RemoteControl ** Message: has_config_widget 00:XX:XX:XX:XX:66 Headset_-_AG ** Message: has_config_widget 00:XX:XX:XX:XX:66 HandsfreeAudioGateway ** Message: has_config_widget 00:XX:XX:XX:XX:66 Phonebook_Access_-_PSE ** Message: Default Bluetooth adapter is powered
So what's happening here is:
+ Trace 230639
which apparently doesn't bother to compare the currently selected device against the previously selected device, and only emit the signal if the selected device actually changed: static void device_model_row_changed (GtkTreeModel *model, GtkTreePath *path, GtkTreeIter *iter, gpointer data) { BluetoothChooser *self = BLUETOOTH_CHOOSER (data); BluetoothChooserPrivate *priv = BLUETOOTH_CHOOSER_GET_PRIVATE(self); char *address; /* Not the selection changing? */ if (gtk_tree_selection_path_is_selected (priv->selection, path) == FALSE) return; g_object_notify (G_OBJECT (self), "device-selected"); address = bluetooth_chooser_get_selected_device (self); g_signal_emit (G_OBJECT (self), selection_table_signals[SELECTED_DEVICE_CHANGED], 0, address); g_free (address); }
Since this *is* still the selected device changing, the "Not the selection changing?" bit doesn't trigger. The comment is wrong, because the currently selected device *can* can change without the selecting having changed.
Created attachment 222646 [details] [review] bluetooth: Don't break the custom widgets on connect We used to destroy and recreate the custom widgets whenever any of the properties changed. Now we make sure that the custom widgets are only destroyed and recreated when the device selected is a different one. This fixes NetworkManager's Bluetooth plugins getting destroyed because the Connected property changed, as it was trying to connect to the device.
Let me know whether that fixes the problem for you.
Pushed to gnome-3-4 and master Attachment 222646 [details] pushed as 12a3198 - bluetooth: Don't break the custom widgets on connect