bluetooth-properties crashed with signal 5 while adding HID device

[Basilio Kublik]

Binary package hint: bluez-gnome

i was connecting to a hid device through the bluetooth-properties interface, when it disconnects from the bluetooth device at the other end and then the application crash

ProblemType: Crash
Architecture: i386
Date: Sun Dec 30 12:13:10 2007
DistroRelease: Ubuntu 8.04
ExecutablePath: /usr/bin/bluetooth-properties
NonfreeKernelModules: ath_hal
Package: bluez-gnome 0.14-0ubuntu2
PackageArchitecture: i386
ProcCmdline: bluetooth-properties
ProcCwd: /home/sourcer
ProcEnviron:
 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
 LANG=es_CL.UTF-8
 SHELL=/bin/bash
Signal: 5
SourcePackage: bluez-gnome
StacktraceTop:
 ?? () from /usr/lib/libdbus-glib-1.so.2
 ?? ()
Title: bluetooth-properties crashed with signal 5
Uname: Linux ideafix 2.6.24-2-generic #1 SMP Thu Dec 20 17:36:12 GMT 2007 i686 GNU/Linux
UserGroups: adm admin audio cdrom dialout dip floppy lpadmin netdev plugdev powerdev sambashare scanner src video

[Apport retracing service (apport)]

StacktraceTop:dbus_g_proxy_begin_call_internal (proxy=0x81fd760, method=<value optimized out>,
dbus_g_proxy_call (proxy=0x81fd760, method=0x8057e4b "GetAdapter", error=0x0,
proxy_callback (proxy=0x80bd038, call=0x2, user_data=0x80b9228) at input.c:76
d_pending_call_notify (dcall=0x82fc000, data=0x82fdd70) at dbus-gproxy.c:1728
_dbus_pending_call_complete (pending=0x82fc000) at dbus-pending-call.c:198

[RobotII (pete-arthur)]

Confirming this bug, as I am able to reproduce. The problem persists in 0.15-0ubuntu2 as well as the version reported below.

[KDS (karidaserious)]

I think I have a similar problem when trying to connect my Logitech MX5000 BT keyboard and mouse. The keyboard pairs with my computer properly but when I try to connect to my mouse the applet crashes always. So I thought I should inform about this here. I dont know if this helps but if I run the applet from terminal and reproduce the bug It prints this:

** ERROR **: Out of memory
aborting...

I have 2 gigs of ram in my computer so I think thats not the problem :D

[Matti Lindell (mlind)]

Try to delete your gadget (and trust for it) from the 'Bonded devices' list in the Preferences view. Then pair the device again. Does the problem persist?

[Basilio Kublik (sourcercito)]

Hi Matti
Your suggestion actually works for me, I delete the device, then add the input device, wait until ask me to pair, the pairing goes alright and was automagically added as a trusted device. Since i did this, i can connect and disconnect, delete it from input devices and add it again without crash even after untrust the device.

Thanks for the workaround.

[Paul Leger (pleger)]

I have the same errors

[thecure (keith-k)]

confirm. But I am unable to connect device after deleting device then adding device again. 64bit Hardy

[litemotiv (nospam-capstone)]

When trying to pair a Logitech DiNovo Edge under Xubuntu Hardy:

process 16094: arguments to dbus_message_new_method_call() were incorrect, assertion "_dbus_check_is_valid_path (path)" failed in file dbus-message.c line 1074.
This is normally a bug in some application using the D-Bus library.

** ERROR **: Out of memory
aborting...

Why is this bug only listed as 'medium'? Wasn´t proper Bluetooth operation part of the connectivity plan for Hardy?

[Down (downindustries)]

Microsoft Keyboard Elite for Bluetooth & Microsoft IntelliMouse for Bluetooth
i386 Ubuntu 8.04 Alpha 6 with all updates, I keep current everyday.

The keyboard just doesn't want to connect. If I goto input service then add as I press the Make/Break Connection button on the keyboard it pops up but asks for passkey then crashes if one is not entered. When I try passkey of "0000" or "1234" it doesn't crash but its of no use still.

I have been able to get the mouse connected and working after some reading and messing around. But after install nothing just popped up to help connect Bluetooth keyboard & mouse on it's own. I had to manually go into the Bluetooth preferences and muck around. Not so user friendly, but still better then Fedora or Ubuntu 7.10 but PCLinuxOS owns when it comes to Bluetooth. Both Keyboard & Mouse worked with out any setup what so ever. I was even able to use them both during the install process unlike Ubuntu or Fedora.

I really wish Ubuntu was like PCLOS with Bluetooth devices working without any configuration needed.
It's really a pain having 2 of everything hooked up just to install.

P.S. I would attach the crash reports if I knew where they were located. I did tell it to uploaded them so hopefully that worked?

[jhmos (jhmos)]

I got the signal 5 crash the first time I attempted to connect my Logitech MX1000 bluetooth mouse (using Bluetooth -> Preferences -> Services-> Input Service->Add->Connect). However I tried a second time (without rebooting) and to my delight it worked fine, including having it magically start working as a display input device. Have to find out how that works, used to have to edit xorg.conf.

I also uploaded the crash report but don't know how to attach (could have cut and pasted from the crash report window I suppose but did not think of it then). I had just done a package update and reboot though so the versions should be the latest today.
I am using a Dell Inspiron 6400 with nvidia drivers.

This was in /var/log/messages but I assume that it was from the second working attempt:
Mar 11 13:13:34 john-laptop kernel: [ 2464.967486] Bluetooth: HIDP (Human Interface Emulation) ver 1.2
Mar 11 13:13:34 john-laptop kernel: [ 2464.968271] input: Logitech MX1000 mouse as /devices/pci0000:00/0000:00:1d.3/usb4/4-2/4-2.1/4-2.1:1.0/hci0/acl0007617FD71A/input/input10

This extract from syslog might be to do with the crash and later successful attempt:
Mar 11 13:10:30 john-laptop audio[7504]: /org/bluez/audio: org.bluez.audio.Manager.ListDevices()
Mar 11 13:10:30 john-laptop input[7510]: /org/bluez/input: org.bluez.input.Manager.ListDevices()
Mar 11 13:10:56 john-laptop NetworkManager: <debug> [1205201456.526536] nm_hal_device_added(): New device added (hal udi is '/org/freedesktop/Hal/devices/bluetooth_acl_7617fd71a').
Mar 11 13:10:56 john-laptop input[7510]: Incoming connection on PSM 17
Mar 11 13:10:56 john-laptop input[7510]: Incoming connection on PSM 19
Mar 11 13:11:09 john-laptop input[7510]: /org/bluez/input: org.bluez.input.Manager.CreateSecureDevice()
Mar 11 13:11:17 john-laptop hcid[7490]: connect(): Connection timed out (110)
Mar 11 13:11:17 john-laptop input[7510]: GetRemoteServiceHandles: org.bluez.Error.ConnectionAttemptFailed(Connection timed out)
Mar 11 13:11:17 john-laptop NetworkManager: <debug> [1205201477.673999] nm_hal_device_removed(): Device removed (hal udi is '/org/freedesktop/Hal/devices/bluetooth_acl_7617fd71a').
Mar 11 13:12:51 john-laptop audio[7504]: /org/bluez/audio: org.bluez.audio.Manager.ListDevices()
Mar 11 13:12:51 john-laptop input[7510]: /org/bluez/input: org.bluez.input.Manager.ListDevices()
Mar 11 13:13:16 john-laptop input[7510]: /org/bluez/input: org.bluez.input.Manager.CreateSecureDevice()
Mar 11 13:13:16 john-laptop NetworkManager: <debug> [1205201596.415533] nm_hal_device_added(): New device added (hal udi is '/org/freedesktop/Hal/devices/bluetooth_acl_7617fd71a').
Mar 11 13:13:20 john-laptop input[7510]: Created input device: /org/bluez/input/pointing0
Mar 11 13:13:20 john-laptop input[7510]: /org/bluez/input/pointing0: org.bluez.input.Device.GetAdapter()
Mar 11 13:13:20 john-laptop input[7510]: /org/bluez/input/pointing0: org.bluez.input.Device.GetAddress()
Mar 11 13:13:20 john-laptop input[7510]: /org/bluez/input/pointing0: org.bluez.input.Device.GetName()
Mar 11 13:13:20 john-laptop input[7510]: /org/bluez/input/pointing0: org.bluez.input.Device.GetAdapter()
Mar 11 13:13:20 john-laptop input[7510]: /org/b...

[jhmos (jhmos)]

I reinstalled with Hardy Alpha6 and updates and found that I could not get it to work with the default packages. The mouse would not appear as an input service but would appear as a bondable device in the front preferences page. Not remembering what I did last time, I tried adding gnome-bluetooth 0.9.1-0ubuntu1 to no avail then bluetooth 3.26-0ubuntu3.
Not sure if it was just the bluetooth package but or a combination but the mouse then appeared as an input device and the second connect attempt I made worked. The first attempt didn't seem to do anything but no error message appeared (no crash as in my previous report).
I will try to undo the changes I made and attempt to reproduce the problem when I get a chance.

[jhmos (jhmos)]

Just doing a complete remove of the 2 packages did not stop the mouse from working. Furthermore, removal, recinding trust, a reboot and then switching the mouse on brought up an authorization popup which I have never seen before.
Afraid I might have to do a complete reinstall to try to replicate the initial mouse communication problem.

[Michael Favia (michaelfavia)]

Attempted to pair a new input device. (bt keyboard) and bluetooth-properties crashed with the following error message:

michaelfavia@lithium:~$ bluetooth-properties
process 11741: arguments to dbus_message_new_method_call() were incorrect, assertion "_dbus_check_is_valid_path (path)" failed in file dbus-message.c line 1074.
This is normally a bug in some application using the D-Bus library.

** ERROR **: Out of memory
aborting...
Aborted (core dumped)

Crash is reproducible and will always happen if you wait to type in the authorization code when attempting to pair the device.

strace attached. Willing to test anything please advise if helpful. using hidd a s a workaround until resolved as explained here (#191704)

[Matti Lindell (mlind)]

Does this still happen with bluez-gnome 0.25-0ubuntu1 ?

[litemotiv (nospam-capstone)]

Matti, yes unfortunately it still does, same error as Michael Favia reports.

Logitech BT indicator starts to blink on gdm login, and does allow itself to be paired. However, apart from the pair-code no input is sent over and the program crashes with the out of memory error during handshake process. Restarting it shows the paired connection, but it's non functioning.

[Ricky Campbell (cyberdork33)]

I get the same issue when trying to add an Apple Wireless Keyboard, although I get no messages, it just closes.

This process does get it working, but it does not reconnect automatically after the connection is lost:
http://ubuntuforums.org/showthread.php?p=4486290

As I posted in #191704:

I've noticed that, in the process of inputting the dbus commands, the devices gets added in the "Input service" list like it should be. This does not usually happen (when adding via the applet).

Further tinkering shows that I can select the keyboard in the "Bonded devices" list and disconnect it and upon pressing a key on the keyboard it will try to connect but seemingly fails. issuing only the last command I previously posted (the actual connect command) gets the keyboard working again.

[litemotiv (nospam-capstone)]

I can confirm this bug is now fixed.

bluez-gnome is still at 0.25-0ubuntu1 though, so i have no idea what fixed it (kernel modules?).

[Matti Lindell (mlind)]

This could be related to bug #209715 which was fixed recently. Does anyone still experience this issue?

[Ricky Campbell (cyberdork33)]

It is not "crashing" anymore (not being detected anyway), but my keyboard still does not work in the end.

[litemotiv (nospam-capstone)]

It works fine now here, following these steps:

- remove existing device (if present) with bluetooth-applet
- add device under services -> input service
- press pairing button on keyboard
- select found device
- enter passkey on main keyboard [enter] -> enter passkey on bluetooth keyboard
- wait 2-3 seconds and all is set

Rebooting the computer also produces a working connection.

The only problem remaining is that the connection is dropped when the system goes into standby. I need to manually disconnect the keyboard under Bonded Devices and press connect again to regain function.

[Ricky Campbell (cyberdork33)]

Nope. still does not work.

Someone made a script from my previously posted commands and it works as well.
http://ubuntuforums.org/showthread.php?p=4486290

[Robert Lange (rcl24)]

This bug affects me too. I am using the latest hardy as of the timestamp on this comment, and my bluetooth conf files have not been altered manually.

I have a *small* amount of time I can devote to working on this bug. I have discovered the bug that causes the bluetooth-properties application to crash. However, while I can show how to avoid the crash, I do not know how to fix the underlying problem yet.

This specific crash occurs because a call to dbus_g_proxy_end_call does not check the return value or the error value of the function call, and therefore propagates an uninitialized variable to a later dbus function call. I have attached a diff that can be applied to bluez-gnome-0.25/properties/input.c to demonstrate that the error can be trapped before the crash occurs. However, right now I don't have time to implement the proper error handling, so the code just prints a more informative message, before continuing with the original, erroneous control flow.

Someone more familiar with the project can hopefully explain why the dbus call fails in the first place, and how to prevent it from failing.

Hopefully, this hint will allow someone to implement correct handling of the dbus messaging system, so that these dbus errors are never propagated to the user.

[Robert Lange (rcl24)]

For the record, when I trapped the error that was causing the crash, this is the message it gave:

CreateSecureDevice failed with error := 4; Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

[Robert Lange (rcl24)]

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.

[Robert Lange (rcl24)]

Attached is a patch that fixes the crash bug described here. Using the information from comments 25-27, I caught the timeout and notified the user that the authentication had failed.

Also, I modified the dbus timeout to be longer than the bluetooth authentication handshake timeout. The result is that the error message sent to users informs them that the authentication timed out. If I had not done this, users would simply get a generic, uninformative timeout message.

What will it take to get this patch into hardy-updates? It fixes a crash-bug that is confusing a lot of bluetooth users.

Also, any help pushing this patch upstream would be appreciated.

This is not a terribly elegant solution; there is some room for improvement. Specifically, I would like to know how to programmatically obtain the exact timeout length for the bluetooth authentication handshake, so that I can set the dbus timeout to be 1 millisecond longer. (This will allow us to catch dbus errors that do not involve bluetooth timeouts in the minimum amount of time.) Right now, I have just hard-coded the dbus timeout to be 5 minutes, which seems to be well longer than the bluetooth timeout.

[Martin Kaufmann (martin.kaufmann)]

Hi,

here is an debdiff which includes your Patch

[Martin Kaufmann (martin.kaufmann)]

ups forget the attachment, here the debdiff

[Martin Pitt (pitti)]

Taking for sponsoring. Robert, Martin, can either of you please submit the bug and patch upstream? You are much more qualified to explain it than me. Thanks!

[Martin Pitt (pitti)]

Martin, bluez-gnome uses a proper patch system (cdbs simple-patchsys.mk). Please redo your debdiff to use it instead of patching the code inline.

https://wiki.ubuntu.com/PackagingGuide/PatchSystems

[erik_swe (erik-erlandsson)]

Jag är på tjänsteresa tom. 26/9, brådskande ärenden hänvisas till <email address hidden> eller 08 448 38 80

I"m out of office until Sept 29, in urgent matters mail <email address hidden> or call [phone]

[Mario Limonciello (superm1)]

The dbus timeout issue should be resolved in bluez-gnome 1.8. Devices using authentication will properly tell you when to enter the key. If you don't enter it, there will be a proper timeout.

The upstream gnome bug also includes comments that this is fixed there too.

[Ricky Campbell (cyberdork33)]

Mario, since you changed the status to "Fix Released" on the Ubuntu bug, does this mean that bluez-gnome 1.8 is in Intrepid already?

[Onkar Shinde (onkarshinde)]

@Ricky,

Yes, bluez-gnome 1.8 and newer bluez stack (4.x) has entered in intrepid post beta release.

[Ricky Campbell (cyberdork33)]

Well, I had my bluetooth device working just fine in Intrepid until the update of the bluetooth stuff.

The new Deveice setup wizard looks excellent, but unfortunately, now when trying to pair with my keyboard, it just says it failed with no further info. I was using the information found here:
http://idebian.wordpress.com/2008/07/06/manage-hid-bluetooth-devices-in-linux/

This explains that I need to reset the bluetooth adapter into hci mode, which I did, still no luck. This is further complicated by the dissapearance (again) of the hidd binary, but that is another bug...