Trouble with python sync_block and dynamic flow graph reconfiguration

GNU Radio
1

I can’t get dynamic reconfiguration to work when my flow graph has a
sync_block implemented in Python. If I lock() and then disconnect() and
connect() other blocks, my program always hangs on the unlock(). It
won’t
even stop when I hit ctrl-c. Superficial debugging shows that a thread
is
stuck on a sem_wait() somewhere. Figuring out exactly where it is would
take me quite some time as I’m not familiar with that section of the GNU
Radio code. (Considering I wrote the sync_block in Python to save some
time, re-implementing it in C++ would be quicker for me than tracking
down
this potential bug.)

I did search the mailing list, but I couldn’t find anyone discussing
this
issue. At least not with the search terms I used.

I realize that it is entirely possible I’m simply doing it wrong so I
wrote
a (minimal) example that demonstrates my problem. (Attached.)

I should include information about my GNU Radio install, but I’m not
sure
what would be useful. I use Arch Linux and can’t run the build-gnuradio
script directly, but I followed it as an example. I wanted to get 3.7
so I
installed from the git master branch. The last commit in my repo is
be73b3035c184cf09e1051deaba20eca88de8c9d . If any other information
about
my system would be useful in tracking this down, please tell me.

Here is an example run of the attached program. Note how the first test
using all GNU Radio C++ primitives works as expected. The example only
hangs when I try and lock()/unlock() the flow graph that contains my
simple
Python sync_block.

Any ideas?

$ ./unconnect_test.py -h

2

Hi Joshua,

You will be pleased to know that it still works even after leaving it
for 5
minutes:

m@mi7:~/Downloads$ ./unconnect_test.py -h
Usage: unconnect_test.py: [options]

Options:
-h, --help show this help message and exit
-f Run failing test (with python sync_block) or passing test
(without python sync_block)
m@mi7:~/Downloads$ ./unconnect_test.py
Running until enter is pressed:
Setting new sink.
Unlocking…
Using Volk machine: avx_64_mmx_orc
Unlocked
Hit Enter to quit:
Finished.
m@mi7:~/Downloads$ ./unconnect_test.py -f
my_sink: init 60067920
Running until enter is pressed: my_sink: work: 32768
my_sink: work: 32767
my_sink: work: 32768
my_sink: work: 32767
my_sink: work: 32768
my_sink: work: 32767
my_sink: work: 32768
my_sink: work: 32767
my_sink: work: 32768
my_sink: work: 32767
my_sink: work: 32768
my_sink: work: 32767
my_sink: work: 32768
<----snip---->

I’ve just looked at the git log and I am also using the same version as
you:

commit be73b3035c184cf09e1051deaba20eca88de8c9d

I am using Ubuntu 12.04 LTS x64 with a Quad Core i7/8GB Ram and GNU
Radio/UHD was built with pybombs.

Regards,

Mike

–
Mike J. M0MIK BSc MIET
Ettus R. Technical Support
Email: [email protected]
Web: http://www.ettus.com http://www.ettus.com

3

Hi again,

I forgot to press enter so the issue does happen on my end too:

m@mi7:~/Downloads$ time ./unconnect_test.py -f
my_sink: init 36995152
Running until enter is pressed: my_sink: work: 32768
my_sink: work: 32767
my_sink: work: 32768
my_sink: work: 32767
my_sink: work: 32768
my_sink: work: 32767

Setting new sink.
my_sink: init 36995472
Unlocking…
^C^Z
[1]+ Stopped ./unconnect_test.py -f

real 2m45.886s
user 0m0.000s
sys 0m0.000s

I’ll have a look into it.

Regards,

Mike

–
Mike J. M0MIK BSc MIET
Ettus R. Technical Support
Email: [email protected]
Web: http://www.ettus.com http://www.ettus.com

4

Yes, I did try that as a temporary fix.

While it seems to work just fine in the simple example, my more
complicated
program locked up after a few stop()/start()s. I decided that tracking
the
problem with the temporary fix would be just as difficult. (And
ultimately
pointless when the problem with lock()/unlock() is figured out.)

I’m re-implementing in C++ now so please don’t feel any bug-fix pressure
from me. I’m interested to hear the root cause though when you figure
it
out.

Thanks for verifying that this really is a bug.

5

Hi Joshua,

For a temporary workaround, replace tb.lock() with:

tb.stop()
tb.wait()

…and replace tb.unlock() with:

tb.start()

This works for me:

pydev debugger: starting
my_sink: init 48050448
Running until enter is pressed: my_sink: work: 32768
my_sink: work: 32767
my_sink: work: 32768
my_sink: work: 32767
my_sink: work: 32768

Setting new sink.
my_sink: init 48051728
Unlocking…
Unlocked
Hit Enter to quit: my_sink: work: 32768
my_sink: work: 32767
my_sink: work: 32768
my_sink: work: 32767

Finished.

See attached for working version.

Regards,

Mike

–
Mike J. M0MIK BSc MIET
Ettus R. Technical Support
Email: [email protected]
Web: http://www.ettus.com http://www.ettus.com

6

On Tue, Sep 17, 2013 at 4:15 PM, Joshua L. [email protected] wrote:

Thanks for verifying that this really is a bug.

Could you enter this as an issue in our ticket system? You’ll have to
register an account and let us know so we can manually set your ability
to
create issues. But I’d like this to at least be documented so when we
have
time we can go back and work on this.

Thanks.