PR https://github.com/gnuradio/gnuradio/pull/5772 adds a call to deactivateStream() right before closeStream(). We'll need to do a little testing with various Soapy modules to make sure that they all handle this correctly. The SoapyRTLSDR module calls deactivateStream() itself from closeStream() - need to make sure that doesn't cause any problems. But the majority of the modules expect us to call deactivateStream().
Thanks for tracking this down. On Sun, Apr 17, 2022 at 7:02 AM Jeff Long <willco...@gmail.com> wrote: > This could be something we need to change in the in-tree gr-soapy. You can > post an issue to https://github.com/gnuradio/gnuradio/issues and we'll > take a closer look to make sure we're using the SoapySDR AP correctly. > > On Sat, Apr 16, 2022 at 10:29 PM Cinaed Simson <cinaed.sim...@gmail.com> > wrote: > >> >> >> On 4/16/22 14:53, Gavin Jacobs wrote: >> >> I had previously thought that there was an issue with the save/restore of >> the geometry of the QT window, but I determined that it was a problem when >> using the gr-soapy block with a hackrf, so I have started a new thread. >> >> If I make a flowgraph using the "Soapy hackrf source" (i.e. gr-soapy >> block with a hackrf yml), it works fine when receiving the streaming data, >> but crashes the top block on exit. When I stop the flowgraph, I get the >> following message on the console area: >> >>> Done (return code -11) >> I now know that means a segmentation fault, and thanks to Vasil, I tried >> to debug it. The offending code is in a callback and references some memory >> that is no longer around, probably because all the blocks are shutting down >> and calling their respective destructors. So, I then disabled the gr-soapy >> source, and used the gr-osmosdr source (soapy=0,driver=hackrf). This worked >> as expected, including a normal message: >> >>> Done >> So, I compared the way the gr-osmosdr used soapyHackrf with the way >> gr-soapy does it, and I found that: >> gr-osmosdr calls deactivateStream() on stop(), and closeStream() on >> ~destructor() >> gr-soapy never calls deactivateStream(), calls closeStream() on stop(), >> and does nothing in ~destructor() >> >> My assessment is that gr-soapy should follow the pattern previously used >> in gr-osmosdr. The call to deactivateStream() stops the streaming and >> cancels the callback, so the problem would be fixed. A workaround is to use >> the gr-osmosdr/soapy/hackrf block, but it is marked as deprecated, so that >> won't do for long term. >> >> Is there anyone with a hackrf that can verify the problem? and then, how >> to register a bug report? >> >> Jake >> >> >> Try posting an issue >> >> https://github.com/pothosware/SoapyHackRF >> >> -- Cinaed >> >>
