SEGFAULT in bluetoothd after pairing

SEGFAULT in bluetoothd after pairing

[Per Waagø]

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.

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.

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

Re: SEGFAULT in bluetoothd after pairing

[Luiz Augusto von Dentz]

Hi Per,

On Tue, Aug 8, 2017 at 1:19 PM, Per Waag=C3=B8 <pwaago@cisco.com> 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 us=
ed
> 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(str=
uct
> btd_adapter *adapter)
>         addr =3D btd_adapter_get_address(adapter);
>         database->le_io =3D bt_io_listen(connect_cb, NULL, NULL, NULL, &g=
err,
>                                         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_LO=
W,
>                                         BT_IO_OPT_INVALID);
>
> The source type eventually end up as l2_bdaddr_type in the address assign=
ed
> 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 s=
et
> 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.

> Unfortunately, I haven't been able to get a sensible stack trace. Debug l=
ogs
> from pairing is requested until segfault is pasted at the bottom of the
> email.
>
> 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=3D2
> src/device.c:bonding_request_new() Requesting bonding for 50:1A:A5:D6:6C:=
7E
> src/agent.c:agent_ref() 0xda708: ref=3D3
> src/agent.c:agent_unref() 0xda708: ref=3D2
> src/adapter.c:suspend_discovery()
> src/adapter.c:adapter_bonding_attempt() hci0 bdaddr 50:1A:A5:D6:6C:7E typ=
e 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 connecte=
d
> 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=3D1
> 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 ty=
pe
> 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=3D1
> src/device.c:load_gatt_db() Restoring 50:1A:A5:D6:6C:7E gatt database fro=
m
> 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: 0x=
0a
> 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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



--=20
Luiz Augusto von Dentz

Re: SEGFAULT in bluetoothd after pairing

[Per Waagø]

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@cisco.com> 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.
>>
>> 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@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>

Re: SEGFAULT in bluetoothd after pairing

[Konrad Zapalowicz]

On 08/08, 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@cisco.com> 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.

Exactly same issue as I have observed and reported some time ago
https://www.spinics.net/lists/linux-bluetooth/msg70176.html

Mine was with Sony SBH52 headset, Per what kind of headsets are
triggering this behavior on your side?

Best,
K

> 
> >>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.
> >>
> >>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@vger.kernel.org
> >>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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: SEGFAULT in bluetoothd after pairing

[Per Waagø]

On 08. aug. 2017 13:04, Konrad Zapalowicz wrote:
> On 08/08, 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@cisco.com> 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.
> Exactly same issue as I have observed and reported some time ago
> https://www.spinics.net/lists/linux-bluetooth/msg70176.html
>
> Mine was with Sony SBH52 headset, Per what kind of headsets are
> triggering this behavior on your side?
>
> Best,
> K
Both Plantronics Focus and Jabra Evolve 75 are triggering it.

Plantronics Legend and Jabra Supreme are not.


>>>> 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.
>>>>
>>>> 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@vger.kernel.org
>>>> 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@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: SEGFAULT in bluetoothd after pairing

[Konrad Zapalowicz]

On 08/08, Per Waagø wrote:
> 
> 
> On 08. aug. 2017 13:04, Konrad Zapalowicz wrote:
> >On 08/08, 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@cisco.com> 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.
> >Exactly same issue as I have observed and reported some time ago
> >https://www.spinics.net/lists/linux-bluetooth/msg70176.html
> >
> >Mine was with Sony SBH52 headset, Per what kind of headsets are
> >triggering this behavior on your side?
> >
> >Best,
> >K
> Both Plantronics Focus and Jabra Evolve 75 are triggering it.
> 
> Plantronics Legend and Jabra Supreme are not.

Pn my side Philips 5500 is not triggering it. At least v5.44, I have not
yet tried v5.46 (but will do soon).

> 
> 
> >>>>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.
> >>>>
> >>>>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@vger.kernel.org
> >>>>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@vger.kernel.org
> >>More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: SEGFAULT in bluetoothd after pairing

[Per Waagø]

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@cisco.com> 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@vger.kernel.org
>>> 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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: SEGFAULT in bluetoothd after pairing

[Luiz Augusto von Dentz]

Hi Per,

On Wed, Aug 9, 2017 at 12:18 PM, Per Waag=C3=B8 <pwaago@cisco.com> wrote:
>
>
> On 08. aug. 2017 12:55, Per Waag=C3=B8 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=C3=B8 <pwaago@cisco.com> wrote=
:
>>>>
>>>> I am working on implementing bluetooth headset support on a system wit=
h
>>>> a
>>>> Marvell 88W8787 chip. Starting with bluez 5.44 bluetoothd is segfaulti=
ng
>>>> every time I pair with some headset models. I have done a git bisect a=
nd
>>>> 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 struc=
t
>>>> 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 =3D btd_adapter_get_address(adapter);
>>>>          database->le_io =3D 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 i=
s
>>>> 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. Debu=
g
>>>> logs
>>>> from pairing is requested until segfault is pasted at the bottom of th=
e
>>>> email.
>
>
> By hard coding the address type to BDADDR_BREDDR I was able to trigger th=
e
> same crash on my ubuntu box. Then I could run with valgrind and get a sta=
ck
> trace (latest commit in tree was 4364085). The segfault seems to happen w=
hen
> dereferencing the device pointer in browse_cb.
>
> =3D=3D13178=3D=3D Invalid read of size 8
> =3D=3D13178=3D=3D    at 0x1842EA: browse_cb (device.c:4595)
> =3D=3D13178=3D=3D    by 0x15EFA8: search_completed_cb (sdp-client.c:205)
> =3D=3D13178=3D=3D    by 0x194ADC: sdp_process (sdp.c:4354)
> =3D=3D13178=3D=3D    by 0x15F0F4: search_process_cb (sdp-client.c:230)
> =3D=3D13178=3D=3D    by 0x4E84229: g_main_context_dispatch (in
> /lib/x86_64-linux-gnu/libglib-2.0.so.0.5200.0)
> =3D=3D13178=3D=3D    by 0x4E845DF: ??? (in
> /lib/x86_64-linux-gnu/libglib-2.0.so.0.5200.0)
> =3D=3D13178=3D=3D    by 0x4E84901: g_main_loop_run (in
> /lib/x86_64-linux-gnu/libglib-2.0.so.0.5200.0)
> =3D=3D13178=3D=3D    by 0x120AFF: main (main.c:781)
>
> I have verified by inserting log statements that it is crashing in the sa=
me
> spot on the embedded system.

Are you sure you have the following patch:

https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/?id=3D006213cf4d2=
31ce66de273e96619474bd516359b

>
>>>>
>>>> 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=3D2
>>>> src/device.c:bonding_request_new() Requesting bonding for
>>>> 50:1A:A5:D6:6C:7E
>>>> src/agent.c:agent_ref() 0xda708: ref=3D3
>>>> src/agent.c:agent_unref() 0xda708: ref=3D2
>>>> 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 kern=
el
>>>> 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 discove=
ry
>>>> src/agent.c:agent_unref() 0xda708: ref=3D1
>>>> 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=3D1
>>>> 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 service=
s:
>>>> 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@vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>>>
>>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-bluetoot=
h"
>> in
>> the body of a message to majordomo@vger.kernel.org
>> 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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



--=20
Luiz Augusto von Dentz

Re: SEGFAULT in bluetoothd after pairing

[Per Waagø]

On 09. aug. 2017 11:47, Luiz Augusto von Dentz wrote:
> Hi Per,
>
> On Wed, Aug 9, 2017 at 12:18 PM, Per Waagø <pwaago@cisco.com> wrote:
>>
>> 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@cisco.com> 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.
> Are you sure you have the following patch:
>
> https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/?id=006213cf4d231ce66de273e96619474bd516359b
>

Yes, I verified it now.

>>>>> 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@vger.kernel.org
>>>>> 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@vger.kernel.org
>>> 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@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>