I have a rather complex flowgraph that used to work well with GNU Radio 3.7.
I upgraded to 3.8.1, and now it crashes (for some input, but even when I
use /dev/zero as file source) with something that looks like in the core of
GNU Radio (not directly in the block).
Environment:
GNU Radio 3.8.1
Python 3.8.2
Ubuntu 16.04.6
There are many blocks, but let's focus on the last ones.
I have a float-to-int block (the standard one) which feeds data into a sink
block that is written in Python. In case it is relevant, this is the block
that feeds the sink: *float_to_int =
blocks.float_to_int(); self.connect(float_to_int, sink)*
The process crashes with a segmentation fault.
If I nullify the Python sink (commenting out all real processing code in
work()), the issue still happens.
Furthermore, I wrote a "my_null_sink" block in Python (see code below). It
still crashes with the same issue (after I connected it to the float-to-int
output instead of the original Python sink).
When I replace "my_null_sink" with GNU Radio's standard Null Sink, it
doesn't crash anymore.
Using the same input file and my_null_sink, it crashes about 95% of the
runs (i.e., not 100%, but almost always), with Null Sink, 0%.
That's why I believe it is something with the Python binding. I do have
other Python blocks in the flowgraph (one that is connected to the file
source and does some simple processing before passing forward the samples).
When I run it with gdb, I catch the exception and the stack trace is below.
The 2nd frame in the stack sends us to *block_gateway_impl.cc:139*, work(),
*_handler->calleval(0);*
The 1st stack frame doesn't have an associated module for the specified
address (0x0000000002324b90 in ??), "i sh" shows it isn't associated with
any module, and "info symbol <addr>" confirms this. I also witness that all
modules are loaded into addresses > 0x00007f1300000000, so I assume the
address from the stack trace is really not a valid library, but some
garbage (it's also very close to 0).
The faulty memory address tends to change which is another indication for
garbage.
Note: when I build the app in Debug, another stack frame appears between
the one that isn't associated with a module, to the one in
block_gateway_impl:
*include/gnuradio/py_feval.h:69* which is *py_eval_ll::calleval(int)*:
*return eval(x);*
When I implement the simplest flowgraph: File Source with /dev/zero ->
Throttle -> my_null_sink, it doesn't crash.
In the original flowgraph, I disabled almost all blocks, and specifically,
I did not leave any enabled own C++ block - just to rule out the
possibility that one of the blocks corrupts the memory. It didn't change
anything.
I tested it on another machine with a similar setup (GNU Radio 3.8.1) and
it reproduced. On an older machine, still with GNU Radio 3.7.11.1, it works
(doesn't crash).
Any ideas will be appreciated.
------
*my_null_sink.py*
*import numpyfrom gnuradio import grclass my_null_sink(gr.sync_block):
def __init__(self): gr.sync_block.__init__( self,
name="my_null_sink", in_sig=[numpy.int32],
out_sig=None) print('***** my_null_sink init') def work(self,
input_items, output_items): return len(input_items[0])*
*Exception in GDB*
*Thread 20 "my_null_sink25" received signal SIGSEGV, Segmentation fault*
*#0 0x0000000002324b90 in ?? ()#1 0x00007f5ec43df433 in
gr::block_gateway_impl::work (this=this@entry=0x2324fc0, noutput_items=8,
input_items=std::vector of length 1, capacity 1 = {...},
output_items=std::vector of length 0, capacity 0) at
/home/user/gr/src/gnuradio/gnuradio-runtime/lib/block_gateway_impl.cc:139#2
0x00007f5ec43df471 in gr::block_gateway_impl::general_work
(this=0x2324fc0, noutput_items=<optimized out>, ninput_items=...,
input_items=std::vector of length 1, capacity 1 = {...}, output_items=...)
at
/home/user/gr/src/gnuradio/gnuradio-runtime/lib/block_gateway_impl.cc:121#3
0x00007f5ec43dc4c4 in gr::block_executor::run_one_iteration
(this=this@entry=0x7f5e71ffadf0) at
/home/user/gr/src/gnuradio/gnuradio-runtime/lib/block_executor.cc:514#4
0x00007f5ec4439097 in gr::tpb_thread_body::tpb_thread_body
(this=0x7f5e71ffadf0, block=..., start_sync=...,
max_noutput_items=<optimized out>) at
/home/user/gr/src/gnuradio/gnuradio-runtime/lib/tpb_thread_body.cc:122#5
0x00007f5ec4428932 in gr::tpb_container::operator() (this=0x2ab6640) at
/home/user/gr/src/gnuradio/gnuradio-runtime/lib/scheduler_tpb.cc:50#6
gr::thread::thread_body_wrapper<gr::tpb_container>::operator()
(this=0x2ab6640) at
/home/user/gr/src/gnuradio/gnuradio-runtime/lib/../include/gnuradio/thread/thread_body_wrapper.h:52#7
boost::detail::function::void_function_obj_invoker0<gr::thread::thread_body_wrapper<gr::tpb_container>,
void>::invoke (function_obj_ptr=...) at
/usr/include/boost/function/function_template.hpp:159#8 0x00007f5ec4444260
in boost::function0<void>::operator() (this=<optimized out>) at
/usr/include/boost/function/function_template.hpp:773#9
boost::detail::thread_data<boost::function0<void> const>::run
(this=<optimized out>) at
/usr/include/boost/thread/detail/thread.hpp:116#10 0x00007f5ec27fc5d5 in ??
() from /usr/lib/x86_64-linux-gnu/libboost_thread.so.1.58.0#11
0x00007f5ee913a6ba in start_thread (arg=0x7f5e71ffb700) at
pthread_create.c:333#12 0x00007f5ee831d41d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:109*
ᐧ
