Bug 1059494

Summary: [abrt] NetworkManager: bluez_disconnect_cb(): NetworkManager killed by SIGSEGV (when bluetooth tethering with an iPhone)
Product: [Fedora] Fedora Reporter: lilis
Component: NetworkManagerAssignee: Dan Williams <dcbw>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 20CC: abaxter, awilliam, dcbw, jesse_kahtava, jklimes, j.quincunx, lilis
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
URL: https://retrace.fedoraproject.org/faf/reports/bthash/82aa1844b95ddd53192658b1b672bea2ebfd03be
Whiteboard: abrt_hash:fd77683d6fdf1ffdbe525938396964700995260a
Fixed In Version: NetworkManager-0.9.9.0-39.git20131003.fc20 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-06-15 01:51:50 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
File: backtrace
none
File: cgroup
none
File: core_backtrace
none
File: dso_list
none
File: environ
none
File: exploitable
none
File: limits
none
File: maps
none
File: open_fds
none
File: proc_pid_status
none
File: var_log_messages none

Description lilis 2014-01-29 23:51:59 UTC
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

Comment 1 lilis 2014-01-29 23:52:03 UTC
Created attachment 857299 [details]
File: backtrace

Comment 2 lilis 2014-01-29 23:52:05 UTC
Created attachment 857300 [details]
File: cgroup

Comment 3 lilis 2014-01-29 23:52:07 UTC
Created attachment 857301 [details]
File: core_backtrace

Comment 4 lilis 2014-01-29 23:52:09 UTC
Created attachment 857302 [details]
File: dso_list

Comment 5 lilis 2014-01-29 23:52:11 UTC
Created attachment 857303 [details]
File: environ

Comment 6 lilis 2014-01-29 23:52:13 UTC
Created attachment 857304 [details]
File: exploitable

Comment 7 lilis 2014-01-29 23:52:15 UTC
Created attachment 857305 [details]
File: limits

Comment 8 lilis 2014-01-29 23:52:17 UTC
Created attachment 857306 [details]
File: maps

Comment 9 lilis 2014-01-29 23:52:20 UTC
Created attachment 857307 [details]
File: open_fds

Comment 10 lilis 2014-01-29 23:52:22 UTC
Created attachment 857308 [details]
File: proc_pid_status

Comment 11 lilis 2014-01-29 23:52:24 UTC
Created attachment 857309 [details]
File: var_log_messages

Comment 12 Jirka Klimes 2014-01-31 13:35:42 UTC
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().

Comment 13 Adam Baxter 2014-03-20 18:45:44 UTC
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.

Comment 14 Adam Williamson 2014-04-08 18:26:54 UTC
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).

Comment 15 Dan Williams 2014-04-09 16:17:50 UTC
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.

Comment 16 Jirka Klimes 2014-06-12 12:05:27 UTC
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

Comment 17 Fedora Update System 2014-06-12 14:08:50 UTC
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

Comment 18 Fedora Update System 2014-06-13 05:29:57 UTC
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).

Comment 19 Fedora Update System 2014-06-15 01:51:50 UTC
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.

Comment 20 Jirka Klimes 2014-06-23 10:21:57 UTC
*** Bug 1110879 has been marked as a duplicate of this bug. ***