After turning off SELinux to work around bug #295121, I successfully connected with a Bluetooth keyboard (Nokia SU-8W). After power cycling the keyboard, it did not reconnect -- it only does that if we actually pair with it (hcitool auth 00:0E:ED:9A:61:98). I used the bluetooth-properties tool to search again, and tried to connect to the keyboard. The tool aborted with the same dbus error message reported in bug 295121: process 11729: 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. After deleting the existing entry for the SU-8W under the input service, I was able to successfully connect to it again.
Mind breaking on dbus_message_new_method_call and see which call is causing the problem? Which version of bluez-* are you using?
Current rawhide: bluez-utils-3.19-1.fc8 bluez-libs-3.19-1.fc8 bluez-gnome-0.14-2.fc8 #2 0x0f5143e8 in _dbus_abort () at dbus-sysdeps.c:86 #3 0x0f50e5d4 in _dbus_warn_check_failed ( format=0xf51f8b4 "arguments to %s() were incorrect, assertion \"%s\" failed in file %s line %d.\nThis is normally a bug in some application using the D-Bus library.\n") at dbus-internals.c:283 #4 0x0f50043c in dbus_message_new_method_call ( destination=0x10322e50 ":1.94", path=0x103224c0 "", interface=0x10306890 "org.bluez.input.Device", method=0x10011ec4 "GetAdapter") at dbus-message.c:1074 #5 0x0f5594c4 in dbus_g_proxy_marshal_args_to_message (proxy=0x102cee10, method=0x10011ec4 "GetAdapter", args=0x102c3dd0) at dbus-gproxy.c:2118 #6 0x0f559a18 in dbus_g_proxy_begin_call_internal (proxy=0x102cee10, method=0x10011ec4 "GetAdapter", notify=0, user_data=0x0, destroy=0, args=0x102c3dd0, timeout=-1) at dbus-gproxy.c:2157 #7 0x0f55dc14 in dbus_g_proxy_call (proxy=0x102cee10, method=0x10011ec4 "GetAdapter", error=0x0, first_arg_type=0) at dbus-gproxy.c:2522 #8 0x1000bb38 in proxy_callback (proxy=<value optimized out>, call=0x2, user_data=0x10076c50) at input.c:76
This is what happens when I press connect, when the keyboard is already known... Breakpoint 1, dbus_message_new_method_call (destination=0x1008f810 ":1.94", path=0x1008f820 "/org/bluez/input", interface=0x1008fca0 "org.bluez.input.Manager", method=0x10011f0c "CreateDevice") at dbus-message.c:1070 1070 _dbus_return_val_if_fail (path != NULL, NULL); (gdb) c Continuing. Breakpoint 1, dbus_message_new_method_call ( destination=0xf51b958 "org.freedesktop.DBus", path=0xf51b970 "/org/freedesktop/DBus", interface=0xf51b958 "org.freedesktop.DBus", method=0xf51b994 "AddMatch") at dbus-message.c:1070 1070 _dbus_return_val_if_fail (path != NULL, NULL); (gdb) Continuing. Breakpoint 1, dbus_message_new_method_call (destination=0x10313e08 ":1.94", path=0x1030bd48 "", interface=0x103355c0 "org.bluez.input.Device", method=0x10011ec4 "GetAdapter") at dbus-message.c:1070 1070 _dbus_return_val_if_fail (path != NULL, NULL); (gdb) Continuing. process 12230: 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. D-Bus not built with -rdynamic so unable to print a backtrace Program received signal SIGABRT, Aborted. 0x0f32f1f0 in raise () from /lib/libc.so.6
And this is when it works... Breakpoint 1, dbus_message_new_method_call (destination=0x1008f810 ":1.94", path=0x1008f820 "/org/bluez/input", interface=0x1008fca0 "org.bluez.input.Manager", method=0x10011f0c "CreateDevice") at dbus-message.c:1070 1070 _dbus_return_val_if_fail (path != NULL, NULL); (gdb) Continuing. Breakpoint 1, dbus_message_new_method_call ( destination=0xf51b958 "org.freedesktop.DBus", path=0xf51b970 "/org/freedesktop/DBus", interface=0xf51b958 "org.freedesktop.DBus", method=0xf51b994 "AddMatch") at dbus-message.c:1070 1070 _dbus_return_val_if_fail (path != NULL, NULL);
Oops, missed part from comment 4. It continues... Breakpoint 1, dbus_message_new_method_call (destination=0x10316ea0 ":1.94", path=0x1030c7e8 "/org/bluez/input/keyboard5", interface=0x103186e8 "org.bluez.input.Device", method=0x10011ec4 "GetAdapter") at dbus-message.c:1070 1070 _dbus_return_val_if_fail (path != NULL, NULL); (gdb) Continuing. Breakpoint 1, dbus_message_new_method_call (destination=0x10316ea0 ":1.94", path=0x1030c7e8 "/org/bluez/input/keyboard5", interface=0x103186e8 "org.bluez.input.Device", method=0x10011e38 "GetAddress") at dbus-message.c:1070 1070 _dbus_return_val_if_fail (path != NULL, NULL); (gdb) Continuing. Breakpoint 1, dbus_message_new_method_call (destination=0x10316ea0 ":1.94", path=0x1030c7e8 "/org/bluez/input/keyboard5", interface=0x103186e8 "org.bluez.input.Device", method=0x100119d8 "GetName") at dbus-message.c:1070 1070 _dbus_return_val_if_fail (path != NULL, NULL); (gdb) Continuing.
The CreateDevice call seems to be failing because the device already exists. This may be a bluez-utils bug. I'm not entirely sure how we're supposed to ask it to reconnect to a previously-connected HIDevice.
Patch posted to bluez-devel list today to fix this.
Still a problem on rawhide?
This is 6 months old, and David didn't complain anymore, let's say it's fixed.
Actually we still have issues today, trying to connect to an already-known device with the wizard. You have to remove the pairing first, then repair with it. You can't just reconnect.
(In reply to comment #10) > Actually we still have issues today, trying to connect to an already-known > device with the wizard. You have to remove the pairing first, then repair with > it. You can't just reconnect. But it doesn't crash, right? Could you file a new bug with the reproducer steps? I'll try and fix that this coming week.