Re: Weird Python Sinks Crash with GNU Radio 3.8.1

[Volker Schroer]

Tested on Ubuntu 19.10 with python 3.7.5

Crashing.

Backtrace gives

Thread 3 "my_null_sink4" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffe8939700 (LWP 7033)]
0x7265bed1 in gr::py_feval_ll::calleval(long) () from
/usr/local/gnuradio/lib/python3/dist-packages/gnuradio/gr/_runtime_swig.so
(gdb) bt
#0  0x7265bed1 in gr::py_feval_ll::calleval(long) () from
/usr/local/gnuradio/lib/python3/dist-packages/gnuradio/gr/_runtime_swig.so
#1  0x76caf2ea in gr::block_gateway_impl::work(int,
std::vector >&,
std::vector >&) ()
   from /usr/local/gnuradio/lib/libgnuradio-runtime.so.3.9.0
#2  0x76caf423 in gr::block_gateway_impl::general_work(int,
std::vector >&, std::vector >&, std::vector >&)
() from /usr/local/gnuradio/lib/libgnuradio-runtime.so.3.9.0
#3  0x76cad1a3 in gr::block_executor::run_one_iteration() ()
from /usr/local/gnuradio/lib/libgnuradio-runtime.so.3.9.0
#4  0x76d03093 in
gr::tpb_thread_body::tpb_thread_body(boost::shared_ptr,
boost::shared_ptr, int) () from
/usr/local/gnuradio/lib/libgnuradio-runtime.so.3.9.0
#5  0x76cf498e in
boost::detail::function::void_function_obj_invoker0,
void>::invoke(boost::detail::function::function_buffer&) ()
   from /usr/local/gnuradio/lib/libgnuradio-runtime.so.3.9.0
#6  0x76d105c6 in
boost::detail::thread_data >::run() () from
/usr/local/gnuradio/lib/libgnuradio-runtime.so.3.9.0
#7  0x771f61b5 in ?? () from
/usr/lib/x86_64-linux-gnu/libboost_thread.so.1.67.0
#8  0x77d9c669 in start_thread (arg=) at
pthread_create.c:479
#9  0x77ed8323 in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95


By the way: trying the gnuradio version with pybind instead of swig
crashes too.

-- Volker

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)
>> mailto:gi...@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)
>> mailto:gi...@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 (0x02324b90 in ??), "i sh" shows it
>> isn't associated with any module, and "info symbol "
>> confirms this. I also witness that all modules are loaded into
>> addresses > 0x7f13, 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 

Re: Weird Python Sinks Crash with GNU Radio 3.8.1

[Christophe Seguinot]

  
  
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) 
  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) 
  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,

Re: Weird Python Sinks Crash with GNU Radio 3.8.1

[Gilad Beeri (ApolloShield)]

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) <
gi...@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) <
> gi...@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 (0x02324b90 in ??), "i sh" shows it isn't associated with
>> any module, and "info symbol " confirms this. I also witness that all
>> modules are loaded into addresses > 0x7f13, 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  0x02324b90 in ?? ()#1  0x7f5ec43df433 in
>> 

Re: Weird Python Sinks Crash with GNU Radio 3.8.1

[Gilad Beeri (ApolloShield)]

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) <
gi...@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 (0x02324b90 in ??), "i sh" shows it isn't associated with
> any module, and "info symbol " confirms this. I also witness that all
> modules are loaded into addresses > 0x7f13, 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  0x02324b90 in ?? ()#1  0x7f5ec43df433 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
>  0x7f5ec43df471 in gr::block_gateway_impl::general_work
> (this=0x2324fc0, noutput_items=, ninput_items=...,
> input_items=std::vector of length 1, capacity 1 = {...}, output_items=...)
>   at
> 

Weird Python Sinks Crash with GNU Radio 3.8.1

[Gilad Beeri (ApolloShield)]

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 (0x02324b90 in ??), "i sh" shows it isn't associated with
any module, and "info symbol " confirms this. I also witness that all
modules are loaded into addresses > 0x7f13, 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  0x02324b90 in ?? ()#1  0x7f5ec43df433 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
 0x7f5ec43df471 in gr::block_gateway_impl::general_work
(this=0x2324fc0, noutput_items=, 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
 0x7f5ec43dc4c4 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
 0x7f5ec4439097 in gr::tpb_thread_body::tpb_thread_body
(this=0x7f5e71ffadf0, block=..., start_sync=...,
max_noutput_items=) at
/home/user/gr/src/gnuradio/gnuradio-runtime/lib/tpb_thread_body.cc:122#5
 0x7f5ec4428932 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::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,
void>::invoke (function_obj_ptr=...)at
/usr/include/boost/function/function_template.hpp:159#8  0x7f5ec260
in boost::function0::operator() (this=) at
/usr/include/boost/function/function_template.hpp:773#9
 boost::detail::thread_data const>::run
(this=) at