Hi Yunhan,
On Wed, Oct 25, 2017 at 10:58 AM, Yunhan Wang <yunhanw@xxxxxxxxxxxx> wrote:
> Hi, Luiz
>
> On Tue, Oct 24, 2017 at 1:10 AM, Luiz Augusto von Dentz
> <luiz.dentz@xxxxxxxxx> wrote:
>> Hi Yunhan,
>>
>> On Mon, Oct 23, 2017 at 11:59 PM, Yunhan Wang <yunhanw@xxxxxxxxxxxx> wrote:
>>> Hi, Luiz
>>>
>>> I have tried this, I think the issue is still there with your patch.
>>
>> I don't see any problem:
>>
>> bluetoothd[13968]: src/device.c:att_disconnected_cb() Software caused
>> connection abort (103)
>> bluetoothd[13968]: src/gatt-client.c:btd_gatt_client_disconnected()
>> Device disconnected. Cleaning up.
>> bluetoothd[13968]: src/device.c:att_disconnected_cb() Automatic
>> connection disabled
>> bluetoothd[13968]: attrib/gattrib.c:g_attrib_unref() 0x8897600: g_attrib_unref=0
>> bluetoothd[13968]: src/gatt-database.c:att_disconnected()
>> bluetoothd[13968]: src/gatt-database.c:ccc_write_cb() External CCC
>> write received with value: 0x0000
>>
>> Could you try running under valgrind?
>>
> Yes, just tried under valgrind, the issue is constantly reprodcued.
> Btw, I am currently using btvirt -L -l2, one client, one server, then
> bluetoothd crash after client issue ble disconnect. I am using bluez
> lateset master.
>
> sudo valgrind ./src/bluetoothd --experimental --debug
> ==31609== Jump to the invalid address stated on the next line
> ==31609== at 0x0: ???
> ==31609== by 0x481B4C: queue_foreach (queue.c:220)
> ==31609== by 0x4436C8: att_disconnected (gatt-database.c:310)
> ==31609== by 0x481B4C: queue_foreach (queue.c:220)
> ==31609== by 0x486631: disconnect_cb (att.c:590)
> ==31609== by 0x48FBC4: watch_callback (io-glib.c:170)
> ==31609== by 0x4E7FCE4: g_main_context_dispatch (in
> /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
> ==31609== by 0x4E80047: ??? (in
> /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
> ==31609== by 0x4E80309: g_main_loop_run (in
> /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
> ==31609== by 0x40B51A: main (main.c:770)
> ==31609== Address 0x0 is not stack'd, malloc'd or (recently) free'd
It turns out the ccc_cb->callback could be NULL in case of
svc_changed, though I not sure why in our case it did not have the
last call pointing to clear_ccc_state:
at 0x0: ???
by 0x475C7C: clear_ccc_state (gatt-database.c:287)
by 0x4D28CF: queue_foreach (queue.c:220)
by 0x475FE7: att_disconnected (gatt-database.c:310)
by 0x4D7255: disconn_handler (att.c:538)
by 0x4D28CF: queue_foreach (queue.c:220)
by 0x4D8F39: disconnect_cb (att.c:590)
by 0x4E6B3A: watch_callback (io-glib.c:170)
by 0x50CD246: g_main_context_dispatch (in
/usr/lib64/libglib-2.0.so.0.5200.3)
by 0x50CD5E7: ??? (in /usr/lib64/libglib-2.0.so.0.5200.3)
by 0x50CD901: g_main_loop_run (in /usr/lib64/libglib-2.0.so.0.5200.3)
by 0x40CD90: main (main.c:770)
Address 0x0 is not stack'd, malloc'd or (recently) free'd
Anyway now this should fixed upstream, thanks for the report.
--
Luiz Augusto von Dentz
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
