Comment 27 for bug 179399

Further investigation indicates that the failure described in comments 25 and 26 is caused by a dbus timeout. Dbus links bluetooth-properties, bluetooth-applet, and other intermediary processes, and together, they pair bluetooth devices and configure the system to use those devices. When a remote procedure invocation over dbus fails to return after some specified period of time, dbus times out and returns an error code. The crash occurs because bluetooth-properties assumes the call always completes successfully, and does not check the error code; it therefore passes an uninitialized variable to another function, which triggers the crash.

Bug #230932 in bluez-gnome seems to be the most frequent reason for the timeout. In short, the bluetooth-applet user interface fails to inform the user that he needs to re-enter the passkey on the bluetooth keyboard. If the user waits too long, because he does not know he needs to do anything, then dbus will timeout, triggering the crash.

I stress that merely solving bug #230932 does not fix this bug. Failure to check error codes is always a bug, and it is both hard to find, and easy to avoid in the first place. Furthermore, it is possible that bluetooth pairing will timeout for reasons other than the user not responding quickly enough; we need to check the return code to protect against those cases too.

After dbus times out and bluetooth-properties crashes, the bluetooth-applet can still accept the passkey sequence and complete the bonding. However, the keyboard is still unusable until the user re-opens bluetooth-properties and manually re-attempts to pair the already-bonded keyboard; this time, the process always seems to succeed, as the passkey has already been accepted. However, many users will have already given up in frustration, assuming that bluetooth is broken.

Something needs to be done to prevent dbus from timing out. Hopefully, someone who understands dbus better can help.