Reconfiguring a hier_block2 without locking the top block


#1

Hello all,

Is the code designed so you can .lock() a individual hier_block2 and
reconfigure it without having to lock the overall top_block? IF you do
have
to lock the top block, why?

The code below causes a seg fault on my 3.1.3 and 3.2 installations.

Sample code (http://pastebin.com/d413db7f7):

from gnuradio import gr

class h_block(gr.hier_block2):
def init(self):
gr.hier_block2.init(self, “hello”, gr.io_signature(0, 0, 0),
gr.io_signature(0, 0, 0))
self.source = gr.null_source(gr.sizeof_float)
self.sink = gr.null_sink(gr.sizeof_float)
self.connect(self.source, self.sink)

def reconfigure(self):
    self.lock()
    self.disconnect(self.source, self.sink)
    self.source = gr.null_source(gr.sizeof_float)
    self.connect(self.source, self.sink)
    self.unlock()

class top_block(gr.top_block):
def init(self):
gr.top_block.init(self)
self.h_block = h_block()
self.connect(self.h_block)

if name == ‘main’:
app = top_block()
app.start()
print “Reconfiguring h_block”
app.h_block.reconfigure()
app.stop()

Thank you,
Kieran


#2

On Tue, Mar 17, 2009 at 03:47:54PM +1300, Kieran B. wrote:

Hello all,

Is the code designed so you can .lock() a individual hier_block2 and
reconfigure it without having to lock the overall top_block? IF you do have
to lock the top block, why?

You can lock/unlock on anything derived from from hier_block2 or
top_block.

FWIW, your code works for me using the trunk as of r10628.
That is, it prints “Reconfiguring h_block”, and then hangs.
(The hang is a different bug that will be addressed soon.)

The code below causes a seg fault on my 3.1.3 and 3.2 installations.

If it printed anything before dying, can you please post that?
Can you generate a backtrace from the segfault using gdb?

Eric


#3

On Wed, Mar 18, 2009 at 8:01 AM, Eric B. removed_email_address@domain.invalid wrote:

FWIW, your code works for me using the trunk as of r10628.
That is, it prints “Reconfiguring h_block”, and then hangs.
(The hang is a different bug that will be addressed soon.)

Is the hang coming from the lock? Since it seems to be crashing once it
gets
into an infinite loop while locking.

If it printed anything before dying, can you please post that?

Can you generate a backtrace from the segfault using gdb?

(Ignore the file name - I added the “Locking” to see where in the
sequence
it was crashing)
sdrts@sdrts:~/test$ python multiple_top_block_test.py
Reconfiguring h_block
Locking
Segmentation fault
sdrts@sdrts:~/test$

And backtrace from gdb: (3.1.3 but same thing happens at the same point
in
my 3.2 installation)

app.h_block.reconfigure()

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb7d748c0 (LWP 30961)]
gr_hier_block2::lock (this=0xa012a40) at gr_hier_block2.cc:98
98 gr_hier_block2::lock()
Current language: auto; currently c++
(gdb) backtrace
#0 gr_hier_block2::lock (this=0xa012a40) at gr_hier_block2.cc:98
#1 0xb7afa023 in gr_hier_block2_detail::lock (this=)
at gr_hier_block2_detail.cc:369
#2 0xb7af93f0 in gr_hier_block2::lock (this=0xa012a40) at
gr_hier_block2.cc:100
#3 0xb7afa023 in gr_hier_block2_detail::lock (this=)
at gr_hier_block2_detail.cc:369
#4 0xb7af93f0 in gr_hier_block2::lock (this=0xa012a40) at
gr_hier_block2.cc:100
#5 0xb7afa023 in gr_hier_block2_detail::lock (this=)
at gr_hier_block2_detail.cc:369
#6 0xb7af93f0 in gr_hier_block2::lock (this=0xa012a40) at
gr_hier_block2.cc:100
#7 0xb7afa023 in gr_hier_block2_detail::lock (this=)
at gr_hier_block2_detail.cc:369
#8 0xb7af93f0 in gr_hier_block2::lock (this=0xa012a40) at
gr_hier_block2.cc:100

This goes on for a looong time (I stopped after 30,000 lines).

Thank you,
Kieran