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 numpy
from gnuradio import gr
class 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