Segfault when using Bluetooth audio

[Bruce]

Hi,

Firstly, I freely admit this is an issue with an older GQRX version
2.11, so understand if noone wants to reply.
However, nothing in the changelogs seems to imply to me that this has
been tackled in later versions. It may have been covered in underlying
gnuradio or SoapySDRPlay changes though?
I have specific reasons for sticking with this version, due to a GQRX
fork for a specific application.
I'm happy to manually include later changes if relevant for me, but what
I have is working OK. There would be a lot of pain moving to the latest
GQRX - I've looked into that!

I'm using an RSP2, SoapySDRPlay 0.3, SoapySDR and GQRX 2.11.

Previously I've mentioned audio latency issues (which others have also
suffered with RSP), for which I have a sufficient workaround, but it's a
bit ugly.

I've noted that GQRX crashes with a a Segfault when using BT headphones,
and I move out of range (or back in range when temporarily out-of-range,
I'm unsure which).
If i ensure I turn off BT connection prior to moving away, I can avoid
this problem, but in the application that's not always possible. I'd
like to perhaps force a BT disconnection automatically if I can somehow
detect the situation where the segfault is about to occur, to keep GQRX
running.

In gdb I've tracked this down to a memmove resulting from a memcpy in
SoapySDRPlay::readStream(), which in turn is called from gr-osmosdr.
Looks like it's in its own thread, but I'm not really sure?
Now this relates to comms with the SDR device (RSP), so it's surprising
that something on the audio BT GQRX output side causes this particular
segfault, but it does seem to crash in the same place every time.
My guess is that BT audio buffers fill up, this in turn gets reflected
back through gnuradio modules all the way back to the Soapy input side
(the "buff0" user buffer) somehow not being allocated, or something?
Yes, a very vague guess - it's quite surprising nothing in the whole
chain crashes prior to this.

Anyway, does anyone have a clue what I'm talking about, or seen this
issue themselves?
Has this all been fixed since? If so, where? (I'd look at implementing
just the fix for that)

--
Cheers,
Bruce