Version-Release number of selected component: NetworkManager-0.9.9.0-26.git20131003.fc20 Additional info: reporter: libreport-2.1.11 backtrace_rating: 4 cmdline: /usr/sbin/NetworkManager --no-daemon crash_function: bluez_disconnect_cb executable: /usr/sbin/NetworkManager kernel: 3.12.8-300.fc20.x86_64 runlevel: N 5 type: CCpp uid: 0 Truncated backtrace: Thread no. 1 (5 frames) #0 bluez_disconnect_cb at bluez-manager/nm-bluez-device.c:419 #1 g_simple_async_result_complete at gsimpleasyncresult.c:777 #2 g_dbus_connection_call_done at gdbusconnection.c:5484 #3 g_simple_async_result_complete at gsimpleasyncresult.c:777 #4 complete_in_idle_cb at gsimpleasyncresult.c:789
Created attachment 857299 [details] File: backtrace
Created attachment 857300 [details] File: cgroup
Created attachment 857301 [details] File: core_backtrace
Created attachment 857302 [details] File: dso_list
Created attachment 857303 [details] File: environ
Created attachment 857304 [details] File: exploitable
Created attachment 857305 [details] File: limits
Created attachment 857306 [details] File: maps
Created attachment 857307 [details] File: open_fds
Created attachment 857308 [details] File: proc_pid_status
Created attachment 857309 [details] File: var_log_messages
Is that reproducible? How? static void bluez_disconnect_cb (GDBusConnection *dbus_connection, GAsyncResult *res, gpointer user_data) { NMBluezDevicePrivate *priv = NM_BLUEZ_DEVICE_GET_PRIVATE (user_data); GError *error = NULL; GVariant *variant; variant = g_dbus_connection_call_finish (dbus_connection, res, &error); if (!variant) { ---> nm_log_warn (LOGD_BT, "bluez[%s]: failed to disconnect: %s", priv->path, error->message); g_error_free (error); } else g_variant_unref (variant); } priv is NULL. Most probably NMBluezDevice was freed before. I think we may need to take ref when calling g_dbus_connection_call() in nm_bluez_device_disconnect().
This happens reasonably consistently using my iPhone 5 (iOS 7.1) as a tethered device. Actually, NetworkManager, in general, appears to be unhappy with tethering via iPhone.
clearing needinfo, as several people have confirmed the 'reproducer' here: bluetooth tether to an iPhone running iOS 7.1. (Bryn Reeves confirmed same to me via email).
I can reproduce it while being connected to my iPhone 3GS over Bluetooth PAN and then turning Bluetooth off in the GNOME control center panel. NM receives the Bluez "device removed" message which then triggers removal of the NMDeviceBt object, and since the device was connected, that also calls Bluez Disconnect(), but when the D-Bus call returns, the device is already gone as you hypothesized. So yeah, we do need to ref/unref over the Disconnect() dbus call.
Fixed in upstream master: 948a272 bluetooth: don't crash when switching off bluetooth (rh #1059494) Fedora 20 test scratch-build: http://koji.fedoraproject.org/koji/taskinfo?taskID=7039089
NetworkManager-0.9.9.0-39.git20131003.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/NetworkManager-0.9.9.0-39.git20131003.fc20
Package NetworkManager-0.9.9.0-39.git20131003.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing NetworkManager-0.9.9.0-39.git20131003.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-7329/NetworkManager-0.9.9.0-39.git20131003.fc20 then log in and leave karma (feedback).
NetworkManager-0.9.9.0-39.git20131003.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 1110879 has been marked as a duplicate of this bug. ***