# Python message passing block hangs (test file included) **URL:** \ **Category:** GNU Radio\ **Created:** [March 12, 2015, 10:01pm UTC](https://www.ruby-forum.com/t/python-message-passing-block-hangs-test-file-included/234545 "2015-03-12T22:01:40Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![addis\_a](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c4cdca/32.png) [@addis\_a](https://www.ruby-forum.com/u/addis_a)\ **Post date:** [March 12, 2015, 10:01pm UTC](https://www.ruby-forum.com/t/python-message-passing-block-hangs-test-file-included/234545/1 "2015-03-12T22:01:40Z")
Hi all, I’m struggling to understand an issue I’m having with a simple python block with a registered message port connected to the copy block. The python block looks like this: it literally does nothing, it just happens to have a message port registered: class signal\_sink(gr.sync\_block): def **init** (self): gr.sync\_block. **init** (self, name=“sink”, in\_sig=[np.float32], out\_sig=None) self.signal = pmt.from\_bool(False) self.port\_name = pmt.intern(“sig”) self.message\_port\_register\_out(self.port\_name) def work(self, input\_items, output\_items): return len(input\_items[0]) Then I have a gr.unittest case that connects a vector\_source, the copy block, and the above signal sink: def test\_copy(self): src\_data = np.arange(1000) src = blocks.vector\_source\_f(src\_data) copy = blocks.copy(gr.sizeof\_float) msg\_debug = blocks.message\_debug() sig\_sink = signal\_sink() self.tb.connect(src, copy, sig\_sink) self.tb.msg\_connect(sig\_sink, “sig”, copy, “en”) ``` # Run once (this run is successful) self.tb.run() # Run again (this run hangs) src.rewind() self.tb.run() ``` The second time the flowgraph is “run”, it hangs indefinitely. GDB shows sig\_sink’s thread state as #0 pthread\_cond\_timedwait@@GLIBC\_2.3.2 () at …/nptl/sysdeps/unix/sysv/linux/x86\_64/pthread\_cond\_timedwait.S:238 Commenting out the “self.tb.msg\_connect” line stops the hang, as does connecting sig\_sink’s message port to a message\_debug block (which is not in the flowgraph). All this even though the sig\_sink block doesn’t send any signals over its message port. Any hints would be very much appreciated, my debugging prowess has taken me as far as it’s going to take me. I’ve attached the complete test file that you can run with “python test.py” Thanks in advance, -Doug ---
**Author:** ![AndersonS\_Douglas\_J](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/53a042/32.png) [@AndersonS\_Douglas\_J](https://www.ruby-forum.com/u/AndersonS_Douglas_J)\ **Post date:** [March 15, 2015, 9:11pm UTC](https://www.ruby-forum.com/t/python-message-passing-block-hangs-test-file-included/234545/2 "2015-03-15T21:11:24Z")
On Thu, Mar 12, 2015 at 5:00 PM, Anderson, Douglas J. \< [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)\> wrote: > ``` > gr.sync_block. __init__ (self, name="sink", in_sig=[np.float32], > > ``` > > Then I have a gr.unittest case that connects a vector\_source, the copy > > The second time the flowgraph is “run”, it hangs indefinitely. GDB shows > All this even though the sig\_sink block doesn’t send any signals over its > message port. > > Any hints would be very much appreciated, my debugging prowess has taken > me as far as it’s going to take me. > > I’ve attached the complete test file that you can run with “python test.py” > > Thanks in advance, > -Doug Hi Doug, What version of GNU Radio are you running (gnuradio-config-info -v)? I just tested your test.py script locally and it worked fine. We’ve put in a patch for the shutdown system that I think it’s related to your problem, but it has not been in a version release, yet. The patch is pretty simple: commit 035b9d016dffefec890323bd0b24dbaf23aa9186 Author: Tom R. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Date: Wed Feb 4 13:06:14 2015 +0000 ``` runtime: possible bug fix for limited-run flowgraphs with ``` message-only blocks. diff --git a/gnuradio-runtime/lib/block.cc b/gnuradio-runtime/lib/block.cc index 9173094..f26d6bb 100644 — a/gnuradio-runtime/lib/block.cc +++ b/gnuradio-runtime/lib/block.cc @@ -750,7 +750,10 @@ namespace gr { bool block::finished() { - return d\_finished; - if((detail()-\>ninputs() != 0) || (detail()-\>noutputs() != 0)) - ``` return false; ``` - else - ``` return d_finished; ``` } If you want to give that a try, I’m interested to hear feedback on this problem and solution. Thanks, Tom ---
**Author:** ![AndersonS\_Douglas\_J](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/53a042/32.png) [@AndersonS\_Douglas\_J](https://www.ruby-forum.com/u/AndersonS_Douglas_J)\ **Post date:** [March 16, 2015, 6:10pm UTC](https://www.ruby-forum.com/t/python-message-passing-block-hangs-test-file-included/234545/3 "2015-03-16T18:10:25Z")
Tom, Ironically I was using a GNU Radio git build from Feb 3rd, the day before that patch was merged. I just rebuilt and verified that the test case I attached works now. Thanks! -Doug * * * From: removed\_email\_address@domain.invalid [removed\_email\_address@domain.invalid] on behalf of Tom Rondeau [removed\_email\_address@domain.invalid] Sent: Sunday, March 15, 2015 2:09 PM To: Anderson, Douglas J. Cc: GNURadio D.ion List Subject: Re: [Discuss-gnuradio] Python message passing block hangs (test file included) On Thu, Mar 12, 2015 at 5:00 PM, Anderson, Douglas J. \ wrote: Hi all, I’m struggling to understand an issue I’m having with a simple python block with a registered message port connected to the copy block. The python block looks like this: it literally does nothing, it just happens to have a message port registered: class signal\_sink(gr.sync\_block): def **init** (self): gr.sync\_block. **init** (self, name=“sink”, in\_sig=[np.float32], out\_sig=None) self.signal = pmt.from\_bool(False) self.port\_name = pmt.intern(“sig”) self.message\_port\_register\_out(self.port\_name) def work(self, input\_items, output\_items): return len(input\_items[0]) Then I have a gr.unittest case that connects a vector\_source, the copy block, and the above signal sink: def test\_copy(self): src\_data = np.arange(1000) src = blocks.vector\_source\_f(src\_data) copy = blocks.copy(gr.sizeof\_float) msg\_debug = blocks.message\_debug() sig\_sink = signal\_sink() self.tb.connect(src, copy, sig\_sink) self.tb.msg\_connect(sig\_sink, “sig”, copy, “en”) ``` # Run once (this run is successful) self.tb.run() # Run again (this run hangs) src.rewind() self.tb.run() ``` The second time the flowgraph is “run”, it hangs indefinitely. GDB shows sig\_sink’s thread state as #0 pthread\_cond\_timedwait@@GLIBC\_2.3.2 () at …/nptl/sysdeps/unix/sysv/linux/x86\_64/pthread\_cond\_timedwait.S:238 Commenting out the “self.tb.msg\_connect” line stops the hang, as does connecting sig\_sink’s message port to a message\_debug block (which is not in the flowgraph). All this even though the sig\_sink block doesn’t send any signals over its message port. Any hints would be very much appreciated, my debugging prowess has taken me as far as it’s going to take me. I’ve attached the complete test file that you can run with “python test.py” Thanks in advance, -Doug Hi Doug, What version of GNU Radio are you running (gnuradio-config-info -v)? I just tested your test.py script locally and it worked fine. We’ve put in a patch for the shutdown system that I think it’s related to your problem, but it has not been in a version release, yet. The patch is pretty simple: commit 035b9d016dffefec890323bd0b24dbaf23aa9186 Author: Tom R. \ Date: Wed Feb 4 13:06:14 2015 +0000 ``` runtime: possible bug fix for limited-run flowgraphs with ``` message-only blocks. diff --git a/gnuradio-runtime/lib/block.cc b/gnuradio-runtime/lib/block.cc index 9173094…f26d6bb 100644 — a/gnuradio-runtime/lib/block.cc +++ b/gnuradio-runtime/lib/block.cc @@ -750,7 +750,10 @@ namespace gr { bool block::finished() { - return d\_finished; - if((detail()-\>ninputs() != 0) || (detail()-\>noutputs() != 0)) - ``` return false; ``` - else - ``` return d_finished; ``` } If you want to give that a try, I’m interested to hear feedback on this problem and solution. Thanks, Tom