Kevin,
The radio is released properly when the destructor is called, but it's
not getting called for some reason. I have several C++ tests that work
like a champ, but the Python test doesn't actually release the resources
that were allocated. I even tried assigning my block that talks to the
radio to a variable in self (self.radio) and then setting it to None in the
tearDown method. The resources still are not released. If I stop a GNU
Radio flow graph that uses my block then everything is released just fine.
Even when the Python test finishes (after the second run) the resources are
released. It's just that the resources are not released between the back
to back runs of the same test.
I completely agree that releasing the resources should be tested as
well. This just seems like an odd bug to me. My Python isn't all that
great so it's completely possible that I'm not doing something right =\
-Dave
On Thu, Jun 16, 2016 at 11:24 PM, Kevin Reid <kpr...@switchb.org> wrote:
> On Thu, Jun 16, 2016 at 5:21 PM, Dave NotTelling <dmp250...@gmail.com>
> wrote:
>
>> I have a solution in place right now that works around the second
>> test, but it's nasty. Global variables and whatnot.
>>
>
> You wrote originally that the reason the tests can't be run twice is “the
> radio hardware is never released.” This sounds like a problem that can be
> solved by making sure your test (by way of the code it tests, presumably)
> releases the hardware properly. Then your tests are also testing
> "releasing"!
>
> I recommend this course of action because I have had trouble resulting
> from other people's drivers failing to close/release/reset the hardware
> properly, or to be unable to be opened twice.
>
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
