Received-SPF: pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <CAGpqJgrBtwdauxv03jXsq+8+EG_BW-4QZXryXt-e5Y8HA_5+_g@mail.gmail.com>
 <CABBYNZLLx+zX_XyNjkW99D7HG_6+eZM_MP7EWVVAuuRtf0J6dw@mail.gmail.com>
 <CABBYNZJxVsnGtpnJkCCQtQFKXOiSEV7490me1vjAOOGynCdfUw@mail.gmail.com>
 <CAGpqJgrcxd0iwWUu=VB=MhiSS9+TRMLLsyTjbwQMdJ+6u66u6Q@mail.gmail.com>
 <CABBYNZKTQzEuBpP3YG7=Ms6c-36mnR7qAc4A1XDOLfggDPXXCA@mail.gmail.com> <CAGpqJgraPcsGkoNdzG94JTqwxVaMxUBKtVpNfyvBkuy7TWW_sA@mail.gmail.com>
In-Reply-To: <CAGpqJgraPcsGkoNdzG94JTqwxVaMxUBKtVpNfyvBkuy7TWW_sA@mail.gmail.com>
From:   Arthur Lambert <lambertarthur22@gmail.com>
Date:   Tue, 9 Jun 2020 14:12:27 +0200
Message-ID: <CAGpqJgoYaqGfwQ+j1S2dnoYGk04fZSDcOaZ4=2vmM2W7ceFjhA@mail.gmail.com>
Subject: Re: Segmentation fault in bluetoothd with btgatt-client
To:     Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Cc:     "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk

Hi Luiz,

I have 25 devices running with bluez 5.54 + the fix that you push. I
have always segmentation fault but not very frequently. I have a demon
which is checking that Bluetoothd is always alive. The check is
running every minute.
Two times, my watchdog was able to detect the Bluetoothd was not
running anymore. In both case it was just after a disconnect. But I
dont know if the disconnect is triggered by
the crash on bluetoothd or if the crash happened just after

I cannot reproduce it in a deterministic way. I cannot deploy valgrind
on all device of course. Is there another way to share with you data
to help you to fix/understand the issue?

Arthur.

Le jeu. 4 juin 2020 =C3=A0 10:15, Arthur Lambert
<lambertarthur22@gmail.com> a =C3=A9crit :
>
> Hi Luiz,
>
> I just test your fix! It is working perfectly \o/.
>
> I will probably add a kind of watchdog to check that Bluetoothd is
> always alive on my device to reset
> it in case of failure just in case.
>
> Is it possible that this crash happened when a mobile app tried to
> connect to my embedded device?
> Or is it possible that this issue impacts the cache service/charac
> feature? I am not sure to fully
> understand the perimeter of the issue.
> We have a problem with the cache update for a few weeks. Basically the
> problem is that mobile app is
> doing request on bad characteristics after firmware update with new
> characteristic available.
> The problem was already present but very very rare. On my last
> firmware update, it is more frequent.
> It is like the mobile app is using the old UUID mapping. The issue
> happened after Bluez update from 5.52
> to 5.54. But we are not sure that the issue is related to Bluez. It
> can also be related to the phone.
> It is weird also because the issue happened only with Android and IOS
> is just fine.
>
> Thank you for your quick fix and reply!
>
>
> Le mer. 3 juin 2020 =C3=A0 23:06, Luiz Augusto von Dentz
> <luiz.dentz@gmail.com> a =C3=A9crit :
> >
> > Hi Arthur,
> >
> > On Wed, Jun 3, 2020 at 11:22 AM Arthur Lambert
> > <lambertarthur22@gmail.com> wrote:
> > >
> > > Hi Luiz,
> > > thanks for your reply!
> > >
> > > Sorry I am lazy and stupid. I know that your next question will be
> > > around symbol...
> > >
> > > After removing the binary strip option and enable debug symbol :
> > >
> > > bluetoothd[246]: src/device.c:device_svc_resolved()
> > > /org/bluez/hci0/dev_80_32_53_37_58_A6 err -5
> > > bluetoothd[246]: src/device.c:gatt_debug() Read By Grp Type - start:
> > > 0x00bb end: 0xffff
> > > bluetoothd[246]: src/device.c:gatt_debug() Read By Grp Type - start:
> > > 0x0001 end: 0xffff
> > > bluetoothd[246]: src/device.c:gatt_debug() Read By Type - start:
> > > 0x0001 end: 0x00ba
> > > bluetoothd[246]: src/device.c:gatt_debug() Read By Type - start:
> > > 0x0001 end: 0x00ba
> > > bluetoothd[246]: src/device.c:gatt_debug() Read By Type - start:
> > > 0x002a end: 0x00ba
> > > bluetoothd[246]: src/device.c:gatt_debug() Read By Type - start:
> > > 0x0053 end: 0x00ba
> > > bluetoothd[246]: src/device.c:gatt_debug() Read By Type - start:
> > > 0x007a end: 0x00ba
> > > bluetoothd[246]: src/device.c:gatt_debug() Read By Type - start:
> > > 0x00a3 end: 0x00ba
> > > bluetoothd[246]: src/device.c:gatt_debug() Read By Type - start:
> > > 0x00ba end: 0x00ba
> > > bluetoothd[246]: src/device.c:gatt_debug() Read By Type - start:
> > > 0x0001 end: 0xffff
> > > bluetoothd[246]: src/gatt-database.c:db_hash_read_cb() Database Hash =
read
> > > =3D=3D246=3D=3D Invalid read of size 1
> > > =3D=3D246=3D=3D    at 0x4831BA4: memcpy (vg_replace_strmem.c:1035)
> > > =3D=3D246=3D=3D    by 0x87F3B: read_by_type_read_complete_cb (gatt-se=
rver.c:392)
> > > =3D=3D246=3D=3D    by 0x892AB: pending_read_result (gatt-db.c:145)
> > > =3D=3D246=3D=3D    by 0x8B2FB: gatt_db_attribute_read_result (gatt-db=
.c:1866)
> > > =3D=3D246=3D=3D    by 0x3AB0B: db_hash_read_cb (gatt-database.c:1156)
> > > =3D=3D246=3D=3D    by 0x8B1AB: gatt_db_attribute_read (gatt-db.c:1825=
)
> > > =3D=3D246=3D=3D    by 0x87DB7: process_read_by_type (gatt-server.c:48=
2)
> > > =3D=3D246=3D=3D    by 0x8854F: read_by_type_cb (gatt-server.c:559)
> > > =3D=3D246=3D=3D    by 0x81727: handle_notify (att.c:966)
> > > =3D=3D246=3D=3D    by 0x81873: can_read_data (att.c:1057)
> > > =3D=3D246=3D=3D    by 0x8B91B: watch_callback (io-glib.c:170)
> > > =3D=3D246=3D=3D    by 0x488A413: g_main_context_dispatch (in
> > > /usr/lib/libglib-2.0.so.0.5600.3)
> > > =3D=3D246=3D=3D  Address 0x0 is not stack'd, malloc'd or (recently) f=
ree'd
> > > =3D=3D246=3D=3D
> > > =3D=3D246=3D=3D
> > > =3D=3D246=3D=3D Process terminating with default action of signal 11 =
(SIGSEGV)
> > > =3D=3D246=3D=3D  Access not within mapped region at address 0x0
> > > =3D=3D246=3D=3D    at 0x4831BA4: memcpy (vg_replace_strmem.c:1035)
> > > =3D=3D246=3D=3D    by 0x87F3B: read_by_type_read_complete_cb (gatt-se=
rver.c:392)
> > > =3D=3D246=3D=3D    by 0x892AB: pending_read_result (gatt-db.c:145)
> > > =3D=3D246=3D=3D    by 0x8B2FB: gatt_db_attribute_read_result (gatt-db=
.c:1866)
> > > =3D=3D246=3D=3D    by 0x3AB0B: db_hash_read_cb (gatt-database.c:1156)
> > > =3D=3D246=3D=3D    by 0x8B1AB: gatt_db_attribute_read (gatt-db.c:1825=
)
> > > =3D=3D246=3D=3D    by 0x87DB7: process_read_by_type (gatt-server.c:48=
2)
> > > =3D=3D246=3D=3D    by 0x8854F: read_by_type_cb (gatt-server.c:559)
> > > =3D=3D246=3D=3D    by 0x81727: handle_notify (att.c:966)
> > > =3D=3D246=3D=3D    by 0x81873: can_read_data (att.c:1057)
> > > =3D=3D246=3D=3D    by 0x8B91B: watch_callback (io-glib.c:170)
> > > =3D=3D246=3D=3D    by 0x488A413: g_main_context_dispatch (in
> > > /usr/lib/libglib-2.0.so.0.5600.3)
> > > =3D=3D246=3D=3D  If you believe this happened as a result of a stack
> > > =3D=3D246=3D=3D  overflow in your program's main thread (unlikely but
> > > =3D=3D246=3D=3D  possible), you can try to increase the size of the
> > > =3D=3D246=3D=3D  main thread stack using the --main-stacksize=3D flag=
.
> > > =3D=3D246=3D=3D  The main thread stack size used in this run was 8388=
608.
> > > /usr/bin/bluetoothd: can't resolve symbol '__libc_freeres'
> > >
> > > is it the crypto error that you expect?
> > > Could you share a sha1 commit or a link to the patch to test the pote=
ntial fix?
> >
> > Ive just pushed the fix:
> >
> > commit 41a5413023fa85bc711d461eb736a0624542df2d
> > Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
> > Date:   Wed Jun 3 10:31:59 2020 -0700
> >
> >     gatt: Fix possible crash when unable to generate hash
> >
> >
> > --
> > Luiz Augusto von Dentz
>
>
>
> --
> - Arthur LAMBERT


--=20
- Arthur LAMBERT