On 08. aug. 2017 12:55, Per Waagø wrote:
Hi Luiz,
On 08. aug. 2017 12:46, Luiz Augusto von Dentz wrote:
Hi Per,
On Tue, Aug 8, 2017 at 1:19 PM, Per Waagø <pwaago@xxxxxxxxx> wrote:
I am working on implementing bluetooth headset support on a system
with a
Marvell 88W8787 chip. Starting with bluez 5.44 bluetoothd is
segfaulting
every time I pair with some headset models. I have done a git bisect
and
found that the behavior was introduced with this commit: "f2483bbfd
core:
Fix passing correct local address type to ATT socket"
This commit changes some initializations of BT_IO_OPT_SOURCE_TYPE
that used
to be hard coded to BDADDR_LE_PUBLIC to be read from the adapter struct
instead, using the new btd_adapter_get_address_type function. The
address_type of the adapter is set based on the MGMT_SETTING_LE
flag. The
8787 doesn't support bluetooth LE, so address type is set to
BDADDR_BREDR.
Reverting this chunk eliminates the problem:
--- a/src/gatt-database.c
+++ b/src/gatt-database.c
@@ -2603,7 +2603,8 @@ struct btd_gatt_database
*btd_gatt_database_new(struct
btd_adapter *adapter)
addr = btd_adapter_get_address(adapter);
database->le_io = bt_io_listen(connect_cb, NULL, NULL,
NULL, &gerr,
BT_IO_OPT_SOURCE_BDADDR, addr,
- BT_IO_OPT_SOURCE_TYPE,
BDADDR_LE_PUBLIC,
+ BT_IO_OPT_SOURCE_TYPE,
+ btd_adapter_get_address_type(adapter),
BT_IO_OPT_CID, ATT_CID,
BT_IO_OPT_SEC_LEVEL,
BT_IO_SEC_LOW,
BT_IO_OPT_INVALID);
The source type eventually end up as l2_bdaddr_type in the address
assigned
to the listening socket. From the debug logs I see the connect_cb in
gatt-database.c is called. This does not happen when the source type
is set
to LE_PUBLIC.
The headset is most likely trying to connect ATT over BR/EDR which
perhaps has some unexpected behavior, though we did have some fixes in
this regard so please try with latest upstream.
I did my testing on latest upstream as of Friday. I rebased now and
retested just to be sure,
with the same result.
Unfortunately, I haven't been able to get a sensible stack trace.
Debug logs
from pairing is requested until segfault is pasted at the bottom of the
email.
By hard coding the address type to BDADDR_BREDDR I was able to trigger
the same crash on my ubuntu box. Then I could run with valgrind and get
a stack trace (latest commit in tree was 4364085). The segfault seems to
happen when dereferencing the device pointer in browse_cb.
==13178== Invalid read of size 8
==13178== at 0x1842EA: browse_cb (device.c:4595)
==13178== by 0x15EFA8: search_completed_cb (sdp-client.c:205)
==13178== by 0x194ADC: sdp_process (sdp.c:4354)
==13178== by 0x15F0F4: search_process_cb (sdp-client.c:230)
==13178== by 0x4E84229: g_main_context_dispatch (in
/lib/x86_64-linux-gnu/libglib-2.0.so.0.5200.0)
==13178== by 0x4E845DF: ??? (in
/lib/x86_64-linux-gnu/libglib-2.0.so.0.5200.0)
==13178== by 0x4E84901: g_main_loop_run (in
/lib/x86_64-linux-gnu/libglib-2.0.so.0.5200.0)
==13178== by 0x120AFF: main (main.c:781)
I have verified by inserting log statements that it is crashing in the
same spot on the embedded system.
Any guidance on how to resolve this issue is highly appreciated.
Best regards,
Per
--
src/device.c:btd_device_set_temporary() temporary 0
src/agent.c:agent_ref() 0xda708: ref=2
src/device.c:bonding_request_new() Requesting bonding for
50:1A:A5:D6:6C:7E
src/agent.c:agent_ref() 0xda708: ref=3
src/agent.c:agent_unref() 0xda708: ref=2
src/adapter.c:suspend_discovery()
src/adapter.c:adapter_bonding_attempt() hci0 bdaddr
50:1A:A5:D6:6C:7E type 0
io_cap 0x03
src/adapter.c:add_whitelist_complete() 50:1A:A5:D6:6C:7E added to
kernel
whitelist
src/adapter.c:connected_callback() hci0 device 50:1A:A5:D6:6C:7E
connected
eir_len 22
src/adapter.c:new_link_key_callback() hci0 new key for
50:1A:A5:D6:6C:7E
type 4 pin_len 0 store_hint 1
src/device.c:device_set_bonded()
src/device.c:device_bonding_complete() bonding 0xd8490 status 0x00
src/device.c:device_bonding_complete() Proceeding with service
discovery
src/agent.c:agent_unref() 0xda708: ref=1
src/adapter.c:resume_discovery()
src/adapter.c:pair_device_complete() Success (0x00)
src/adapter.c:bonding_attempt_complete() hci0 bdaddr
50:1A:A5:D6:6C:7E type
0 status 0x0
src/device.c:device_bonding_complete() bonding (nil) status 0x00
src/adapter.c:resume_discovery()
src/gatt-database.c:connect_cb() New incoming BR/EDR ATT connection
attrib/gattrib.c:g_attrib_ref() 0xf7470: g_attrib_ref=1
src/device.c:load_gatt_db() Restoring 50:1A:A5:D6:6C:7E gatt
database from
file
No cache for 50:1A:A5:D6:6C:7E
src/gatt-client.c:btd_gatt_client_connected() Device connected.
src/device.c:gatt_debug() Primary service discovery failed. ATT
ECODE: 0x0a
src/device.c:gatt_client_ready_cb() status: success, error: 0
src/gatt-client.c:btd_gatt_client_ready() GATT client ready
src/gatt-client.c:create_services() Exporting objects for GATT
services:
50:1A:A5:D6:6C:7E
src/device.c:device_svc_resolved()
/org/bluez/hci0/dev_50_1A_A5_D6_6C_7E err
0
--
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
--
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
--
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
