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
