Problems with python blocks [attn: jblum]

I have built a really simple block for testing purposes…

When I run it, I get segmentation faults and source diving has
not revealed the problem to me — there’s a lot of code there, too
much for me it seems.

Am I doing something so horribly wrong?

The build I’m using from jbuml’s git:

  • jblum d393bef gruel: put common swig stuff in gruel_common.

from gnuradio import gr
import math, numpy

class gr_norm(gr.basic_block):
def init(self):
gr.basic_block.init(self, name=“normalizer”,
in_sig=[numpy.complex64], out_sig=[numpy.complex64])

def general_work(self, input_items, output_items):
    in0 = input_items[0]
    out = output_items[0]

    out[0] = in0[0]

    self.consume(0, 1)

    return 1

#!/usr/bin/python2

execfile(“gr_norm.py”)

from gnuradio import gr, gr_unittest
import numpy

class qa_norm(gr_unittest.TestCase):

def setUp(self):
    self.tb = gr.top_block()

def tearDown(self):
    self.tb = None

def test_001_gr_norm(self):
    src_data = [ -10, 10, -10j, 10j ]
    expected_result = [ -1, 1, -1j, 1j ]
    src = gr.vector_source_c(src_data)
    nor = gr_norm()
    dst = gr.vector_sink_c()
    self.tb.connect(src, nor)
    self.tb.connect(nor, dst)
    self.tb.run()
    result_data = dst.data()
    self.assertFloatTuplesAlmostEqual(expected_result, result_data, 

if name == ‘main’:
gr_unittest.main()

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffedaa6700 (LWP 18113)]
0x00007ffff7af908c in PyEval_EvalFrameEx () from
/usr/lib/libpython2.7.so.1.0
#0 0x00007ffff7af908c in PyEval_EvalFrameEx () from
/usr/lib/libpython2.7.so.1.0
#1 0x00007ffff7aff8ef in PyEval_EvalCodeEx () from
/usr/lib/libpython2.7.so.1.0
#2 0x00007ffff7a8c15c in function_call () from
/usr/lib/libpython2.7.so.1.0
#3 0x00007ffff7a67683 in PyObject_Call () from
/usr/lib/libpython2.7.so.1.0
#4 0x00007ffff7a762bf in instancemethod_call () from
/usr/lib/libpython2.7.so.1.0
#5 0x00007ffff7a67683 in PyObject_Call () from
/usr/lib/libpython2.7.so.1.0
#6 0x00007ffff7a67d5d in PyObject_CallMethodObjArgs () from
/usr/lib/libpython2.7.so.1.0
#7 0x00007ffff46ca774 in
SwigDirector_gr_block_gw_handler_safe::call_handle (this=0x1b5ef90)
at
/home/jettero/code/arch/gnuradio/src/build/gnuradio-core/src/lib/swig/gnuradio_core_generalPYTHON_wrap.cxx:6872
#8 0x00007ffff66795f5 in gr_block_gateway_impl::start (this=0x1b7df30)
at
/home/jettero/code/arch/gnuradio/src/gnuradio-core/src/lib/general/gr_block_gateway.cc:171
#9 0x00007ffff660eb37 in gr_block_executor::gr_block_executor
(this=0x7fffedaa5d70, block=)
at
/home/jettero/code/arch/gnuradio/src/gnuradio-core/src/lib/runtime/gr_block_executor.cc:169
#10 0x00007ffff662ea44 in gr_tpb_thread_body::gr_tpb_thread_body
(this=0x7fffedaa5d70, block=…)
at
/home/jettero/code/arch/gnuradio/src/gnuradio-core/src/lib/runtime/gr_tpb_thread_body.cc:32
#11 0x00007ffff6629834 in operator() (this=0x1b773a0) at
/home/jettero/code/arch/gnuradio/src/gnuradio-core/src/lib/runtime/gr_scheduler_tpb.cc:42
#12 operator() (this=0x1b773a0) at
/home/jettero/code/arch/gnuradio/src/gruel/src/include/gruel/thread_body_wrapper.h:50
#13
boost::detail::function::void_function_obj_invoker0<gruel::thread_body_wrapper<tpb_container>,
void>::invoke (function_obj_ptr=…)
at /usr/include/boost/function/function_template.hpp:153
#14 0x00007ffff5e282fe in operator() (this=) at
/usr/include/boost/function/function_template.hpp:760
#15 boost::detail::thread_data<boost::function0 >::run
(this=) at /usr/include/boost/thread/detail/thread.hpp:61
#16 0x00007ffff57c5699 in ?? () from /usr/lib/libboost_thread.so.1.48.0
#17 0x00007ffff7808df0 in start_thread () from /lib/libpthread.so.0
#18 0x00007ffff754e39d in clone () from /lib/libc.so.6
#19 0x0000000000000000 in ?? ()
(gdb)


If riding in an airplane is flying, then riding in a boat is swimming.
116 jumps, 48.6 minutes of freefall, 92.9 freefall miles.

On 12/04/2011 07:14 PM, Paul Miller wrote:

I have built a really simple block for testing purposes…

When I run it, I get segmentation faults and source diving has
not revealed the problem to me — there’s a lot of code there, too
much for me it seems.

Am I doing something so horribly wrong?

Looks like I had a typo in the forecast call, fix is pushed. I should
have had unit testing for the general_work as well.
http://gnuradio.org/cgit/jblum.git/log/?h=python_blocks

I dont really know if thats the cause of the error…?

I attached a copy of your code that worked for me (minus that the unit
test fails since its not really normalizing)

-josh

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs