gr-soapy mishandles hackrf on flowgraph exit

[Gavin Jacobs]

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