Hi Stuart,
On Oct 5, 2008, at 22:07, Stuart Pook wrote:
bluetoothd[15123]: connect(): Connection timed out (110)
==15123== Invalid read of size 4
==15123== at 0x490CBF3: (within /usr/lib/libdbus-1.so.3.4.0)
==15123== by 0x4911DD1: dbus_message_get_sender (in /usr/lib/
libdbus-1.so.3.4.0)
==15123== by 0x49155C0: dbus_message_new_error (in /usr/lib/
libdbus-1.so.3.4.0)
==15123== by 0x1361D: error_common_reply (in /usr/local/stow/
bluez-4.11/sbin/bluetoothd)
==15123== by 0x4ED9D2C: error_connection_attempt_failed (in /usr/
local/stow/bluez-4.11/lib/bluetooth/plugins/audio.so)
==15123== by 0x4EDAEA2: rfcomm_connect_cb (in /usr/local/stow/
bluez-4.11/lib/bluetooth/plugins/audio.so)
==15123== by 0x2165E: connect_cb (in /usr/local/stow/bluez-4.11/
sbin/bluetoothd)
==15123== by 0x48B465C: (within /usr/lib/libglib-2.0.so.0.1600.6)
==15123== by 0x487E1B7: g_main_context_dispatch (in /usr/lib/
libglib-2.0.so.0.1600.6)
==15123== by 0x4881852: (within /usr/lib/libglib-2.0.so.0.1600.6)
==15123== by 0x4881D71: g_main_loop_run (in /usr/lib/
libglib-2.0.so.0.1600.6)
==15123== by 0xA410: main (in /usr/local/stow/bluez-4.11/sbin/
bluetoothd)
==15123== Address 0x464c45b3 is not stack'd, malloc'd or (recently)
free'd
Thanks for the valgrind report. It definitely gives some hints at
what's going on. Apparently there's a bug in one error handling code
path of the rfcomm_connect_cb function. The weird thing here is that
the code path (which calls error_connection_attempt_failed) should
only be taken if the connection attempt was triggered by a D-Bus
message which is not the case for you (it's the alsa sound player that
triggers it, right?). I fixed some issues related to the connection
handling in git but none of it seemed to be directly related to the
backtrace you gave. Could you give the current git a try (git clone
git://git.kernel.org/pub/scm/bluetooth/bluez.git; cd bluez; ./
bootstrap-configure && make)? Also, try to run bluetoothd directly
from the source tree (src/.libs/bluetoothd) so that valgrind can pick
up the correct file names and line numbers as well.
Regarding why this code path is taken, it seems like your alsa
application gives up before the bluetooth connection has been created.
When bluetoothd sees that the alsa client exited it calls close() on
the connecting RFCOMM socket which in effect terminates the connection
creation and causes rfcomm_connect_cb to be called with an error code.
Why your application gives up prematurely is still unclear to me.
Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
