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