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
On 09. aug. 2017 11:47, Luiz Augusto von Dentz wrote:
> Hi Per,
>
> On Wed, Aug 9, 2017 at 12:18 PM, Per Waagø <[email protected]> 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ø <[email protected]> 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 [email protected]
>>>>> 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 [email protected]
>>> 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 [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
Hi Per,
On Wed, Aug 9, 2017 at 12:18 PM, Per Waag=C3=B8 <[email protected]> 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 <[email protected]> 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 [email protected]
>>>> 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 [email protected]
>> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--=20
Luiz Augusto von Dentz
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ø <[email protected]> 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 [email protected]
>>> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
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? <[email protected]> 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 [email protected]
> >>>>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 [email protected]
> >>More majordomo info at http://vger.kernel.org/majordomo-info.html
>
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ø <[email protected]> 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 [email protected]
>>>> 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 [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
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? <[email protected]> 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 [email protected]
> >>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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
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ø <[email protected]> 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 [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
Hi Per,
On Tue, Aug 8, 2017 at 1:19 PM, Per Waag=C3=B8 <[email protected]> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--=20
Luiz Augusto von Dentz