SI-SDR-UG Event 3 -- Save the Date!! -- Saturday April 30
Save-the-Date!! The 3rd event of the South Indian SDR User Group (SI-SDR-UG) will be held on Saturday April 30. The event is free and is fully virtual. Please visit our website for the agenda, and for updates as the date gets closer. https://www.softwaredefinedradio.in/
gr-soapy mishandles hackrf on flowgraph exit
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
Re: gr-soapy mishandles hackrf on flowgraph exit
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
