Re: Weird Python Sinks Crash with GNU Radio 3.8.1

# -*- coding: utf-8 -*-
import os
import signal
import sys

from gnuradio import blocks
from gnuradio import gr

import numpy

class my_null_sink(gr.sync_block):
def __init__(self, item=numpy.uint32, vlen=1):
gr.sync_block.__init__(
self,
name="my_null_sink",
in_sig=[(item, vlen)],
out_sig=None)
# print('***** my_null_sink init ' + self.alias())

def work(self, input_items, output_items):
return len(input_items[0])

class python_sink(gr.top_block):
def __init__(self):
gr.top_block.__init__(self, "Testing Python Sinks")
source1 = blocks.null_source(gr.sizeof_gr_complex)
source2 = blocks.null_source(gr.sizeof_gr_complex)
# null_sink1 = blocks.null_sink(gr.sizeof_gr_complex)
my_null_sink1 = my_null_sink(item=numpy.complex64)
my_null_sink2 = my_null_sink(item=numpy.complex64)

# self.connect(source1, null_sink1)
self.connect(source1, my_null_sink1)
self.connect(source2, my_null_sink2)

# print('Blocked waiting for GDB attach (pid = {})'.format(os.getpid()))
input('Press Enter to continue: ')

def main(top_block_cls=python_sink, options=None):
tb = top_block_cls()

def sig_handler(sig=None, frame=None):
tb.stop()
tb.wait()

sys.exit(0)

signal.signal(signal.SIGINT, sig_handler)
signal.signal(signal.SIGTERM, sig_handler)

tb.start()

tb.wait()

if __name__ == '__main__':
main()

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) <gilad@apolloshield.com> 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) <gilad@apolloshield.com> 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

ᐧ