Re: Weird Python Sinks Crash with GNU Radio 3.8.1

[Marcus Müller]

Sadly, I can reproduce this, too, but only on 3.8; hm.

On 28.04.20 07:59, Christophe Seguinot wrote:
> Hi
> 
> It crashes with a Segmentation fault (core dumped)
> 
>   * Ubuntu 18.04
>   * GNURadio 3.8.1
> 
> 
> On 28/04/2020 07:07, Gilad Beeri (ApolloShield) wrote:
>> Hi,
>> Can someone with GNU Radio 3.8.1 and Python 3.8 on Linux run the
>> attached file and check if it crashes?
>>
>> I get persistent results over several computers for a crash on that
>> setup, while it is ok on Python 2.7 and GNU Radio 3.7.11.
>>
>> ᐧ
>>
>> On Sun, Apr 26, 2020 at 11:19 AM Gilad Beeri (ApolloShield)
>> <address@hidden <mailto:address@hidden>> wrote:
>>
>>     Hi,
>>     I succeeded in narrowing down the flowgraph to a minimal graph
>>     that reproduces the issue. You can see the Python file attached.
>>
>>     Basically, when having a file source that feeds 2 different Null
>>     Python Sinks", the process crashes with a seg fault, with the same
>>     stack trace I showed before:
>>
>>     /include/gnuradio/py_feval.h:69/ which is /py_eval_ll::calleval(int)/:
>>     /return eval(x);/
>>
>>     The flowgraph is very simple:
>>     File Source -> Python Null Sink - 2 times
>>
>>     Replacing one of the Null Python Sinks to a standard Null Sink
>>     "solves" the issue - the crash doesn't reproduce. You can
>>     comment-in line 43 and comment-out line 44 to witness that.
>>     I used the same file source block but I also tested it with 2
>>     different file sources and it behaves the same.
>>
>>     Any ideas why does this happen in GNU Radio 3.8.1?
>>
>>     ᐧ
>>
>>     On Thu, Apr 23, 2020 at 6:50 PM Gilad Beeri (ApolloShield)
>>     <address@hidden <mailto:address@hidden>> wrote:
>>
>>         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/
>>         ᐧ
>>