On Sun, 2019-06-02 at 17:25 +0200, Pali Rohár wrote:
> ---
> src/modules/bluetooth/module-bluez5-device.c | 31
> ++--
> 1 file changed, 29 insertions(+), 2 deletions(-)
>
> diff --git a/src/modules/bluetooth/module-bluez5-device.c
> b/src/modules/bluetooth/module-bluez5
On Monday 17 June 2019 12:36:52 Tanu Kaskinen wrote:
> On Sun, 2019-06-02 at 17:25 +0200, Pali Rohár wrote:
> > ---
> > src/modules/bluetooth/module-bluez5-device.c | 31
> > ++--
> > 1 file changed, 29 insertions(+), 2 deletions(-)
> >
> > diff --git a/src/modules/blueto
setup_stream() crashes when calling set_nonblock() with an invalid
stream_fd.
This crash is due to a race condition.
The audio call starts normally, and a 1st call to setup_stream() is
completed properly.
But, if the call is "quickly" hung up, the stream_fd is in error (POLLHUP)
before other modul
On Saturday 15 June 2019 11:50:10 Tanu Kaskinen wrote:
> Although I made that mistake, I think I'm right in saying that our
> reading logic is broken at least with SBC. The sender can change the
> frame size without warning, so we shouldn't base our read (encoded)
> buffer size on that. If our buff
On Mon, 2019-06-17 at 11:49 +0200, Frédéric Danis wrote:
> setup_stream() crashes when calling set_nonblock() with an invalid
> stream_fd.
>
> This crash is due to a race condition.
> The audio call starts normally, and a 1st call to setup_stream() is
> completed properly.
> But, if the call is "q
